CS IT Support Wiki - User contributions [en]

Notices

2026-11-12T21:52:01Z

Steve410: /* {{red|CS IT SERVICE OUTAGES (Unplanned & Planned)}} */

Notices

2026-11-12T21:50:43Z

Steve410: /* {{red|CS IT SERVICE OUTAGES (Unplanned & Planned)}} */

Notices

2026-11-12T21:15:25Z

Steve410: /* UNPLANNED CS IT SERVICE OUTAGES */

Notices

2026-11-12T21:03:11Z

Steve410: /* UNPLANNED CS IT SERVICE OUTAGES */

Notices

2026-11-12T21:02:58Z

Steve410: /* UNPLANNED CS IT SERVICE OUTAGES */

Notices

2026-11-12T21:00:34Z

Steve410: /* {{red|CS COMPUTING LAB AVAILABILITY}} */

Notices

2026-11-12T21:00:22Z

Steve410: /* {{red|CS COMPUTING LAB AVAILABILITY}} */

Notices

2026-11-12T20:59:39Z

Steve410: /* PLANNED CS IT SERVICE OUTAGES */

Linux Clients on the CS Undergrad Net

2026-11-07T18:28:41Z

Steve410: /* Available Ugrad Linux Systems */

The following is a list of Linux machines available for students, faculty, researchers, or staff. These Linux machines can be accessed remotely via [[Connecting to CS Systems with SSH|<code>ssh</code>]], <code>scp</code> or [[VNC]].

If you're working remotely, although you are welcome to log into '''''any''''' of our Linux clients, it's recommended that you use ''ugradv.cs.jhu.edu'' and ''ugradx.cs.jhu.edu'', as those can handle more concurrent use than any of the lab machines. All of the systems are identically configured, however, so ''anything you can do on one of them can be done on all of the others'', too.

===NOTES===

:* All Ugrad Net systems end with '''''.cs.jhu.edu''''' as in, '''''ugrad1.cs.jhu.edu'''''

:* [[:Category:Accounts|Accounts]], [[:Category:Mail|mail]], [[:Category:Webpages_and_Webservices|web]], and home directories on the Ugrad Net machines ''are different than'' those on the [[Linux Clients on the CS Grad/Research Net|Grad]] systems.

:* Ugrad Net linux clients have [[Disk Quotas|disk quotas]] on the Ugrad home directories.

:* If you are unable to reach one of the systems below, please first see if it is part of an outage by visiting our [[Notices|''Notices'' page]], otherwise, please contact [mailto:support@cs.jhu.edu support@cs.jhu.edu]

:* '''These Linux clients are primarily used for ''educational (coursework)'' purposes.''' Therefore, since you are sharing these systems (CPU, memory, etc.) with other users, please make sure that you do not overload the processors on these systems. When your are completed running your processes, please make sure you stop those processes.

 

==Available Ugrad Linux Systems==

* '''ugrad1''' through '''ugrad12'''
** Standard ''Fedora 44'' Linux clients
** Located in [[:Category:Labs|the CS Undergraduate Lab (Malone 122)]]
** Each client has 8 cores (one 4-core i7 CPU with hyperthreading) and 16 GiB RAM.
** Each system includes an NVIDIA-based GPU that may be used with CUDA and OpenCL (already installed) for coursework.
** ''These systems are also available remotely via [[Connecting to CS Systems with SSH|SSH]] for logins or [https://en.wikipedia.org/wiki/Secure_copy scp] for secure file transfers.''

* '''ugradv''' and '''ugradx'''
** ''Fedora 44'' Linux-based compute servers
** 32 cores (one 16-core Xeon 6511P CPU with hyperthreading), 256 GiB RAM
** Two NVIDIA L4 Tensor Core GPUs
** ''Only available remotely via [[Connecting to CS Systems with SSH|SSH]] for logins or [https://en.wikipedia.org/wiki/Secure_copy scp] for secure file transfers''

* '''ugradz'''
** ''Fedora 44'' Linux-based compute server.
** 32 CPU cores, 48 GiB RAM.
** ''Only available remotely via [[Connecting to CS Systems with SSH|SSH]] for logins or [https://en.wikipedia.org/wiki/Secure_copy scp] for secure file transfers''
** {{red|'''''Only accessible'' from the Hopkins network or VPN;''' not accessible directly from the Internet.}}

'''ssh key fingerprints''' for these machines can be found on the [[SSH Key Fingerprints for Grad and Ugrad Net Linux Computers]] page

[[Category:Linux Clients]]

Linux Clients on the CS Undergrad Net

2026-11-07T18:28:12Z

Steve410: /* Available Ugrad Linux Systems */

The following is a list of Linux machines available for students, faculty, researchers, or staff. These Linux machines can be accessed remotely via [[Connecting to CS Systems with SSH|<code>ssh</code>]], <code>scp</code> or [[VNC]].

If you're working remotely, although you are welcome to log into '''''any''''' of our Linux clients, it's recommended that you use ''ugradv.cs.jhu.edu'' and ''ugradx.cs.jhu.edu'', as those can handle more concurrent use than any of the lab machines. All of the systems are identically configured, however, so ''anything you can do on one of them can be done on all of the others'', too.

===NOTES===

:* All Ugrad Net systems end with '''''.cs.jhu.edu''''' as in, '''''ugrad1.cs.jhu.edu'''''

:* [[:Category:Accounts|Accounts]], [[:Category:Mail|mail]], [[:Category:Webpages_and_Webservices|web]], and home directories on the Ugrad Net machines ''are different than'' those on the [[Linux Clients on the CS Grad/Research Net|Grad]] systems.

:* Ugrad Net linux clients have [[Disk Quotas|disk quotas]] on the Ugrad home directories.

:* If you are unable to reach one of the systems below, please first see if it is part of an outage by visiting our [[Notices|''Notices'' page]], otherwise, please contact [mailto:support@cs.jhu.edu support@cs.jhu.edu]

:* '''These Linux clients are primarily used for ''educational (coursework)'' purposes.''' Therefore, since you are sharing these systems (CPU, memory, etc.) with other users, please make sure that you do not overload the processors on these systems. When your are completed running your processes, please make sure you stop those processes.

 

==Available Ugrad Linux Systems==

* '''ugrad1''' through '''ugrad12'''
** Standard ''Fedora 44'' Linux clients
** Located in [[:Category:Labs|the CS Undergraduate Lab (Malone 122)]]
** Each client has 8 cores (one 4-core i7 CPU with hyperthreading) and 16 GiB RAM.
** Each system includes an NVIDIA-based GPU that may be used with CUDA and OpenCL (already installed) for coursework.
** ''These systems are also available remotely via [[Connecting to CS Systems with SSH|SSH]] for logins or [https://en.wikipedia.org/wiki/Secure_copy scp] for secure file transfers.''

* '''ugradv''' and '''ugradx'''
** ''Fedora 44'' Linux-based compute servers
** 32 cores (one 16-core Xeon 6511P CPU with hyperthreading), 256 GiB RAM
** Two NVIDIA L4 Tensor Core GPUs
** ''Only available remotely via [[Connecting to CS Systems with SSH|SSH]] for logins or [https://en.wikipedia.org/wiki/Secure_copy scp] for secure file transfers''

* '''ugradz'''
** ''Fedora 44'' Linux-based compute server.
** 32 CPU cores, 48 GiB RAM.
** ''Only available remotely via [[Connecting to CS Systems with SSH|SSH]] for logins or [https://en.wikipedia.org/wiki/Secure_copy scp] for secure file transfers''
** {{red|'''''Only accessible''''' from the Hopkins network or VPN; not accessible directly from the Internet.}}

'''ssh key fingerprints''' for these machines can be found on the [[SSH Key Fingerprints for Grad and Ugrad Net Linux Computers]] page

[[Category:Linux Clients]]

Linux Clients on the CS Undergrad Net

2026-11-07T18:27:55Z

Steve410: /* Available Ugrad Linux Systems */

The following is a list of Linux machines available for students, faculty, researchers, or staff. These Linux machines can be accessed remotely via [[Connecting to CS Systems with SSH|<code>ssh</code>]], <code>scp</code> or [[VNC]].

If you're working remotely, although you are welcome to log into '''''any''''' of our Linux clients, it's recommended that you use ''ugradv.cs.jhu.edu'' and ''ugradx.cs.jhu.edu'', as those can handle more concurrent use than any of the lab machines. All of the systems are identically configured, however, so ''anything you can do on one of them can be done on all of the others'', too.

===NOTES===

:* All Ugrad Net systems end with '''''.cs.jhu.edu''''' as in, '''''ugrad1.cs.jhu.edu'''''

:* [[:Category:Accounts|Accounts]], [[:Category:Mail|mail]], [[:Category:Webpages_and_Webservices|web]], and home directories on the Ugrad Net machines ''are different than'' those on the [[Linux Clients on the CS Grad/Research Net|Grad]] systems.

:* Ugrad Net linux clients have [[Disk Quotas|disk quotas]] on the Ugrad home directories.

:* If you are unable to reach one of the systems below, please first see if it is part of an outage by visiting our [[Notices|''Notices'' page]], otherwise, please contact [mailto:support@cs.jhu.edu support@cs.jhu.edu]

:* '''These Linux clients are primarily used for ''educational (coursework)'' purposes.''' Therefore, since you are sharing these systems (CPU, memory, etc.) with other users, please make sure that you do not overload the processors on these systems. When your are completed running your processes, please make sure you stop those processes.

 

==Available Ugrad Linux Systems==

* '''ugrad1''' through '''ugrad12'''
** Standard ''Fedora 44'' Linux clients
** Located in [[:Category:Labs|the CS Undergraduate Lab (Malone 122)]]
** Each client has 8 cores (one 4-core i7 CPU with hyperthreading) and 16 GiB RAM.
** Each system includes an NVIDIA-based GPU that may be used with CUDA and OpenCL (already installed) for coursework.
** ''These systems are also available remotely via [[Connecting to CS Systems with SSH|SSH]] for logins or [https://en.wikipedia.org/wiki/Secure_copy scp] for secure file transfers.''

* '''ugradv''' and '''ugradx'''
** ''Fedora 44'' Linux-based compute servers
** 32 cores (one 16-core Xeon 6511P CPU with hyperthreading), 256 GiB RAM
** Two NVIDIA L4 Tensor Core GPUs
** ''Only available remotely via [[Connecting to CS Systems with SSH|SSH]] for logins or [https://en.wikipedia.org/wiki/Secure_copy scp] for secure file transfers''

* '''ugradz'''
** ''Fedora 44'' Linux-based compute server.
** 32 CPU cores, 48 GiB RAM.
** ''Only available remotely via [[Connecting to CS Systems with SSH|SSH]] for logins or [https://en.wikipedia.org/wiki/Secure_copy scp] for secure file transfers''
** {{red|''Only accessible'' from the Hopkins network or VPN; not accessible directly from the Internet.}}

'''ssh key fingerprints''' for these machines can be found on the [[SSH Key Fingerprints for Grad and Ugrad Net Linux Computers]] page

[[Category:Linux Clients]]

Linux Clients on the CS Undergrad Net

2026-11-07T18:27:38Z

Steve410: /* Available Ugrad Linux Systems */

The following is a list of Linux machines available for students, faculty, researchers, or staff. These Linux machines can be accessed remotely via [[Connecting to CS Systems with SSH|<code>ssh</code>]], <code>scp</code> or [[VNC]].

If you're working remotely, although you are welcome to log into '''''any''''' of our Linux clients, it's recommended that you use ''ugradv.cs.jhu.edu'' and ''ugradx.cs.jhu.edu'', as those can handle more concurrent use than any of the lab machines. All of the systems are identically configured, however, so ''anything you can do on one of them can be done on all of the others'', too.

===NOTES===

:* All Ugrad Net systems end with '''''.cs.jhu.edu''''' as in, '''''ugrad1.cs.jhu.edu'''''

:* [[:Category:Accounts|Accounts]], [[:Category:Mail|mail]], [[:Category:Webpages_and_Webservices|web]], and home directories on the Ugrad Net machines ''are different than'' those on the [[Linux Clients on the CS Grad/Research Net|Grad]] systems.

:* Ugrad Net linux clients have [[Disk Quotas|disk quotas]] on the Ugrad home directories.

:* If you are unable to reach one of the systems below, please first see if it is part of an outage by visiting our [[Notices|''Notices'' page]], otherwise, please contact [mailto:support@cs.jhu.edu support@cs.jhu.edu]

:* '''These Linux clients are primarily used for ''educational (coursework)'' purposes.''' Therefore, since you are sharing these systems (CPU, memory, etc.) with other users, please make sure that you do not overload the processors on these systems. When your are completed running your processes, please make sure you stop those processes.

 

==Available Ugrad Linux Systems==

* '''ugrad1''' through '''ugrad12'''
** Standard ''Fedora 44'' Linux clients
** Located in [[:Category:Labs|the CS Undergraduate Lab (Malone 122)]]
** Each client has 8 cores (one 4-core i7 CPU with hyperthreading) and 16 GiB RAM.
** Each system includes an NVIDIA-based GPU that may be used with CUDA and OpenCL (already installed) for coursework.
** ''These systems are also available remotely via [[Connecting to CS Systems with SSH|SSH]] for logins or [https://en.wikipedia.org/wiki/Secure_copy scp] for secure file transfers.''

* '''ugradv''' and '''ugradx'''
** ''Fedora 44'' Linux-based compute servers
** 32 cores (one 16-core Xeon 6511P CPU with hyperthreading), 256 GiB RAM
** Two NVIDIA L4 Tensor Core GPUs
** ''Only available remotely via [[Connecting to CS Systems with SSH|SSH]] for logins or [https://en.wikipedia.org/wiki/Secure_copy scp] for secure file transfers''

* '''ugradz'''
** ''Fedora 44'' Linux-based compute server.
** 32 CPU cores, 48 GiB RAM.
** ''Only available remotely via [[Connecting to CS Systems with SSH|SSH]] for logins or [https://en.wikipedia.org/wiki/Secure_copy scp] for secure file transfers''
** {{red|Only accessible from the Hopkins network or VPN; not accessible directly from the Internet.}}

'''ssh key fingerprints''' for these machines can be found on the [[SSH Key Fingerprints for Grad and Ugrad Net Linux Computers]] page

[[Category:Linux Clients]]

Linux Clients on the CS Undergrad Net

2026-11-07T18:27:26Z

Steve410: /* Available Ugrad Linux Systems */

The following is a list of Linux machines available for students, faculty, researchers, or staff. These Linux machines can be accessed remotely via [[Connecting to CS Systems with SSH|<code>ssh</code>]], <code>scp</code> or [[VNC]].

If you're working remotely, although you are welcome to log into '''''any''''' of our Linux clients, it's recommended that you use ''ugradv.cs.jhu.edu'' and ''ugradx.cs.jhu.edu'', as those can handle more concurrent use than any of the lab machines. All of the systems are identically configured, however, so ''anything you can do on one of them can be done on all of the others'', too.

===NOTES===

:* All Ugrad Net systems end with '''''.cs.jhu.edu''''' as in, '''''ugrad1.cs.jhu.edu'''''

:* [[:Category:Accounts|Accounts]], [[:Category:Mail|mail]], [[:Category:Webpages_and_Webservices|web]], and home directories on the Ugrad Net machines ''are different than'' those on the [[Linux Clients on the CS Grad/Research Net|Grad]] systems.

:* Ugrad Net linux clients have [[Disk Quotas|disk quotas]] on the Ugrad home directories.

:* If you are unable to reach one of the systems below, please first see if it is part of an outage by visiting our [[Notices|''Notices'' page]], otherwise, please contact [mailto:support@cs.jhu.edu support@cs.jhu.edu]

:* '''These Linux clients are primarily used for ''educational (coursework)'' purposes.''' Therefore, since you are sharing these systems (CPU, memory, etc.) with other users, please make sure that you do not overload the processors on these systems. When your are completed running your processes, please make sure you stop those processes.

 

==Available Ugrad Linux Systems==

* '''ugrad1''' through '''ugrad12'''
** Standard ''Fedora 44'' Linux clients
** Located in [[:Category:Labs|the CS Undergraduate Lab (Malone 122)]]
** Each client has 8 cores (one 4-core i7 CPU with hyperthreading) and 16 GiB RAM.
** Each system includes an NVIDIA-based GPU that may be used with CUDA and OpenCL (already installed) for coursework.
** ''These systems are also available remotely via [[Connecting to CS Systems with SSH|SSH]] for logins or [https://en.wikipedia.org/wiki/Secure_copy scp] for secure file transfers.''

* '''ugradv''' and '''ugradx'''
** ''Fedora 44'' Linux-based compute servers
** 32 cores (one 16-core Xeon 6511P CPU with hyperthreading), 256 GiB RAM
** Two NVIDIA L4 Tensor Core GPUs
** ''Only available remotely via [[Connecting to CS Systems with SSH|SSH]] for logins or [https://en.wikipedia.org/wiki/Secure_copy scp] for secure file transfers''

* '''ugradz'''
** ''Fedora 44'' Linux-based compute server.
** 32 CPU cores, 48 GiB RAM.
** ''Only available remotely via [[Connecting to CS Systems with SSH|SSH]] for logins or [https://en.wikipedia.org/wiki/Secure_copy scp] for secure file transfers''
** {{red!Only accessible from the Hopkins network or VPN; not accessible directly from the Internet.}}

'''ssh key fingerprints''' for these machines can be found on the [[SSH Key Fingerprints for Grad and Ugrad Net Linux Computers]] page

[[Category:Linux Clients]]

Notices

2026-11-05T20:12:39Z

Steve410: /* {{red|CS COMPUTING LAB AVAILABILITY}} */

== {{red|CS IT STAFF AVAILABILITY}} ==

* The CS IT Support staff operates out of Malone Hall. Our group is working a hybrid schedule with some of us working remotely on certain days, while others of our team are on campus.
* We are available M-F, 8:30 to 5pm, but there may be certain times we might be online only.
* Therefore, please remember to email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for assistance.
* Also, please have [https://support.cs.jhu.edu/wiki/Zoom Zoom] available on your device(s), so that we can arrange to contact you using that method, as an alternative to in-person communication.
* Steve DeBlasio, our accounts liaison, is providing a virtual version of his daily office hours for accounts, etc. Email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for details.

 



== {{red|CS IT SERVICE OUTAGES (Unplanned & Planned)}} ==

=== UNPLANNED CS IT SERVICE OUTAGES ===

:None at this time.
 

=== PLANNED CS IT SERVICE OUTAGES ===


====CS Lab Computers ''Un''available and Labs To Be ''Closed'' Due To ACM Contest Event====

:'''WHAT:''' The 1st floor '''CS Ugrad Lab, MH-122''', and the 3rd floor '''CS Masters/MSSI Lab, MH 316/322''' will be closed due to an upcoming ACM Programming Contest. Additionally '''ALL''' of our Linux computers that are located in the CS labs (masters1 through masters4 & ugrad1 through ugrad12) will also be ''un''available as well during that time due to the ACM Programming Contest.

:'''WHEN:'''
:: CS Masters & Ugrad lab Linux systems '''''un'''''available starting '''5pm, Friday, November 6''' and lasting through '''9pm on Saturday, November 7'''.
:: CS Computing Labs physically '''''un'''''available starting '''6am Saturday, November 7 through 11pm''' that same evening.

:'''DETAILS'''

:Although these labs will be closed and the lab computers will be unavailable, you may still remotely access (via ssh) our Grad and Ugrad Linux compute servers that include:

:: gradv.cs.jhu.edu
:: gradx.cs.jhu.edu
:: gradz.cs.jhu.edu

:: ugradv.cs.jhu.edu
:: ugradx.cs.jhu.edu
:: ugradz.cs.jhu.edu

:For a list of our various systems (including our remotely available gradv, gradx, gradz, ugradv, ugradx, & ugradz Linux systems), please see:

::[[Linux_Clients_on_the_CS_Undergrad_Net]]

:::or

::[[Linux_Clients_on_the_CS_Grad/Research_Net]]

:We have to take down the lab systems late that Friday afternoon. At the end of the ACM contest that Saturday night, the coordinators of the contest will be turning our lab computer systems back on. Most should boot normally. But, if some do not, just trying using an alternate one in the lab. (And remember, our compute servers, referenced above, will continue to be available remotely.) We'll be back onsite the Monday afterwards and can check on any systems that didn't boot normally.

:'''NOTE: '''The printers in MH 122 and MH 316/322 will remain online, but, please pick up your printouts outside of the contest hours.


 

== {{red|CS COMPUTING LAB AVAILABILITY}} ==




:'''MH 122''' (CS Undergrad Lab/Collaboration room) will be '''''closed''''' November 7, 2026. Please see the earlier entry on the planned CS lab computer outage for timing details.
 


:'''MH 316/322''' (CS Masters Lab & MSSI Lab) will be '''''closed''''' November 7, 2026. Please see the earlier entry on the planned CS lab computer outage for timing details.

 

== {{red|AUDIO/VISUAL (A/V) OUTAGES}} ==
:None at this time.

[[Category:All]]

Contacting WSE IT Support

2026-10-23T12:58:44Z

Steve410:

While CS ''IT Support'' offers support for certain [[Services_Provided_By_CS_IT|''Computer Science Dept's IT-specific'' services]] and JHU IT offers ''their own'' IT support for its Enterprise services, the '''Whiting School of Engineering (WSE)''' has its own IT Support team for several services WSE offers to various WSE departments. As a CS Department affiliate, many of your CS IT services will come from CS IT Support as outlined in our [[Services_Provided_By_CS_IT|Scope of Services]]. Occasionally, however, for certain services or issues (e.g. related to '''''your own or CS-purchased ''''' computer or to '''''[https://support.cs.jhu.edu/wiki/Category:Research_Computing research computing]''''', etc.), we may refer you to WSE IT. Note that for [https://support.cs.jhu.edu/wiki/Category:Research_Computing research computing support], WSE IT can provide you services for administering your research systems or helping you spec out your research server equipment. Also note that WSE IT now administers the Information Security Institute (ISI) servers and MSSI lab Windows systems.

WSE has their own website at: https://wseit.engineering.jhu.edu/

==If We Refer You To WSE IT...==

If we refer you to WSE IT, you'll need to open up a trouble ticket with them. For example, you might need WSE IT to provide you support for a specific IT service CS doesn't provide, or you might need the answer to a technical question CS IT cannot provide.

===Opening A Trouble Ticket With WSE===

* Email them (with as much detail as possible) at {{mailto|wsehelp@jhu.edu}}
* You will be provided a ticket number for your issue.

[[Category:Misc]]
[[Category:Support Options]]
[[Category:Research Computing]]

Notices

2026-10-16T14:12:47Z

Steve410: /* PLANNED CS IT SERVICE OUTAGES */

== {{red|CS IT STAFF AVAILABILITY}} ==

* The CS IT Support staff operates out of Malone Hall. Our group is working a hybrid schedule with some of us working remotely on certain days, while others of our team are on campus.
* We are available M-F, 8:30 to 5pm, but there may be certain times we might be online only.
* Therefore, please remember to email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for assistance.
* Also, please have [https://support.cs.jhu.edu/wiki/Zoom Zoom] available on your device(s), so that we can arrange to contact you using that method, as an alternative to in-person communication.
* Steve DeBlasio, our accounts liaison, is providing a virtual version of his daily office hours for accounts, etc. Email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for details.

 



== {{red|CS IT SERVICE OUTAGES (Unplanned & Planned)}} ==

=== UNPLANNED CS IT SERVICE OUTAGES ===

:None at this time.
 

=== PLANNED CS IT SERVICE OUTAGES ===


====CS Lab Computers ''Un''available and Labs To Be ''Closed'' Due To ACM Contest Event====

:'''WHAT:''' The 1st floor '''CS Ugrad Lab, MH-122''', and the 3rd floor '''CS Masters/MSSI Lab, MH 316/322''' will be closed due to an upcoming ACM Programming Contest. Additionally '''ALL''' of our Linux computers that are located in the CS labs (masters1 through masters4 & ugrad1 through ugrad12) will also be ''un''available as well during that time due to the ACM Programming Contest.

:'''WHEN:'''
:: CS Masters & Ugrad lab Linux systems '''''un'''''available starting '''5pm, Friday, November 6''' and lasting through '''9pm on Saturday, November 7'''.
:: CS Computing Labs physically '''''un'''''available starting '''6am Saturday, November 7 through 11pm''' that same evening.

:'''DETAILS'''

:Although these labs will be closed and the lab computers will be unavailable, you may still remotely access (via ssh) our Grad and Ugrad Linux compute servers that include:

:: gradv.cs.jhu.edu
:: gradx.cs.jhu.edu
:: gradz.cs.jhu.edu

:: ugradv.cs.jhu.edu
:: ugradx.cs.jhu.edu
:: ugradz.cs.jhu.edu

:For a list of our various systems (including our remotely available gradv, gradx, gradz, ugradv, ugradx, & ugradz Linux systems), please see:

::[[Linux_Clients_on_the_CS_Undergrad_Net]]

:::or

::[[Linux_Clients_on_the_CS_Grad/Research_Net]]

:We have to take down the lab systems late that Friday afternoon. At the end of the ACM contest that Saturday night, the coordinators of the contest will be turning our lab computer systems back on. Most should boot normally. But, if some do not, just trying using an alternate one in the lab. (And remember, our compute servers, referenced above, will continue to be available remotely.) We'll be back onsite the Monday afterwards and can check on any systems that didn't boot normally.

:'''NOTE: '''The printers in MH 122 and MH 316/322 will remain online, but, please pick up your printouts outside of the contest hours.


 

== {{red|CS COMPUTING LAB AVAILABILITY}} ==




:'''MH 122''' (CS Undergrad Lab/Collaboration room) will be closed November 7, 2026. Please see the earlier entry on the planned CS lab computer outage for timing details.
 


:'''MH 316/322''' (CS Masters Lab & MSSI Lab) will be closed November 7, 2026. Please see the earlier entry on the planned CS lab computer outage for timing details.

 

== {{red|AUDIO/VISUAL (A/V) OUTAGES}} ==
:None at this time.

[[Category:All]]

Notices

2026-10-16T14:11:45Z

Steve410: /* CS Lab Computers Unavailable and Labs To Be Closed Due To ACM Contest Event */

== {{red|CS IT STAFF AVAILABILITY}} ==

* The CS IT Support staff operates out of Malone Hall. Our group is working a hybrid schedule with some of us working remotely on certain days, while others of our team are on campus.
* We are available M-F, 8:30 to 5pm, but there may be certain times we might be online only.
* Therefore, please remember to email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for assistance.
* Also, please have [https://support.cs.jhu.edu/wiki/Zoom Zoom] available on your device(s), so that we can arrange to contact you using that method, as an alternative to in-person communication.
* Steve DeBlasio, our accounts liaison, is providing a virtual version of his daily office hours for accounts, etc. Email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for details.

 



== {{red|CS IT SERVICE OUTAGES (Unplanned & Planned)}} ==

=== UNPLANNED CS IT SERVICE OUTAGES ===

:None at this time.
 

=== PLANNED CS IT SERVICE OUTAGES ===


====CS Lab Computers ''Un''available and Labs To Be ''Closed'' Due To ACM Contest Event====

:'''WHAT:''' The 1st floor CS Ugrad Lab, MH-122, and the 3rd floor CS Masters/MSSI Lab, MH 316/322 will be closed due to an upcoming ACM Programming Contest. Additionally '''ALL''' of our Linux computers that are located in the CS labs (masters1 through masters4 & ugrad1 through ugrad12) will also be ''un''available as well during that time due to the ACM Programming Contest.

:'''WHEN:'''
:: CS Masters & Ugrad lab Linux systems '''''un'''''available starting '''5pm, Friday, November 6''' and lasting through '''9pm on Saturday, November 7'''.
:: CS Computing Labs physically '''''un'''''available starting '''6am Saturday, November 7 through 11pm''' that same evening.

:'''DETAILS'''

:Although these labs will be closed and the lab computers will be unavailable, you may still remotely access (via ssh) our Grad and Ugrad Linux compute servers that include:

:: gradv.cs.jhu.edu
:: gradx.cs.jhu.edu
:: gradz.cs.jhu.edu

:: ugradv.cs.jhu.edu
:: ugradx.cs.jhu.edu
:: ugradz.cs.jhu.edu

:For a list of our various systems (including our remotely available gradv, gradx, gradz, ugradv, ugradx, & ugradz Linux systems), please see:

::[[Linux_Clients_on_the_CS_Undergrad_Net]]

:::or

::[[Linux_Clients_on_the_CS_Grad/Research_Net]]

:We have to take down the lab systems late that Friday afternoon. At the end of the ACM contest that Saturday night, the coordinators of the contest will be turning our lab computer systems back on. Most should boot normally. But, if some do not, just trying using an alternate one in the lab. (And remember, our compute servers, referenced above, will continue to be available remotely.) We'll be back onsite the Monday afterwards and can check on any systems that didn't boot normally.

:'''NOTE: '''The printers in MH 122 and MH 316/322 will remain online, but, please pick up your printouts outside of the contest hours.


 

== {{red|CS COMPUTING LAB AVAILABILITY}} ==




:'''MH 122''' (CS Undergrad Lab/Collaboration room) will be closed November 7, 2026. Please see the earlier entry on the planned CS lab computer outage for timing details.
 


:'''MH 316/322''' (CS Masters Lab & MSSI Lab) will be closed November 7, 2026. Please see the earlier entry on the planned CS lab computer outage for timing details.

 

== {{red|AUDIO/VISUAL (A/V) OUTAGES}} ==
:None at this time.

[[Category:All]]

Notices

2026-10-16T14:10:52Z

Steve410: /* CS Lab Computers Unavailable and Labs To Be Closed Due To ACM Contest Event */

== {{red|CS IT STAFF AVAILABILITY}} ==

* The CS IT Support staff operates out of Malone Hall. Our group is working a hybrid schedule with some of us working remotely on certain days, while others of our team are on campus.
* We are available M-F, 8:30 to 5pm, but there may be certain times we might be online only.
* Therefore, please remember to email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for assistance.
* Also, please have [https://support.cs.jhu.edu/wiki/Zoom Zoom] available on your device(s), so that we can arrange to contact you using that method, as an alternative to in-person communication.
* Steve DeBlasio, our accounts liaison, is providing a virtual version of his daily office hours for accounts, etc. Email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for details.

 



== {{red|CS IT SERVICE OUTAGES (Unplanned & Planned)}} ==

=== UNPLANNED CS IT SERVICE OUTAGES ===

:None at this time.
 

=== PLANNED CS IT SERVICE OUTAGES ===


====CS Lab Computers ''Un''available and Labs To Be ''Closed'' Due To ACM Contest Event====

:'''WHAT:''' The 1st floor CS Ugrad Lab, MH-122, and the 3rd floor CS Masters/MSSI Lab, MH 316/322 will be closed due to an upcoming ACM Programming Contest. Additionally '''ALL''' of our Linux computers that are located in the CS labs (masters1 through masters4 & ugrad1 through ugrad12) will also be ''un''available as well during that time due to the ACM Programming Contest.

:'''WHEN:'''
:: Masters & Ugrad lab Linux systems '''''un'''''available starting '''5pm, Friday, November 6''' and lasting through '''9pm on Saturday, November 7'''.
:: Labs physically '''''un'''''available starting '''6am Saturday, November 7 through 11pm''' that same evening.

:'''DETAILS'''

:Although these labs will be closed and the lab computers will be unavailable, you may still remotely access (via ssh) our Grad and Ugrad Linux compute servers that include:

:: gradv.cs.jhu.edu
:: gradx.cs.jhu.edu
:: gradz.cs.jhu.edu

:: ugradv.cs.jhu.edu
:: ugradx.cs.jhu.edu
:: ugradz.cs.jhu.edu

:For a list of our various systems (including our remotely available gradv, gradx, gradz, ugradv, ugradx, & ugradz Linux systems), please see:

::[[Linux_Clients_on_the_CS_Undergrad_Net]]

:::or

::[[Linux_Clients_on_the_CS_Grad/Research_Net]]

:We have to take down the lab systems late that Friday afternoon. At the end of the ACM contest that Saturday night, the coordinators of the contest will be turning our lab computer systems back on. Most should boot normally. But, if some do not, just trying using an alternate one in the lab. (And remember, our compute servers, referenced above, will continue to be available remotely.) We'll be back onsite the Monday afterwards and can check on any systems that didn't boot normally.

:'''NOTE: '''The printers in MH 122 and MH 316/322 will remain online, but, please pick up your printouts outside of the contest hours.


 

== {{red|CS COMPUTING LAB AVAILABILITY}} ==




:'''MH 122''' (CS Undergrad Lab/Collaboration room) will be closed November 7, 2026. Please see the earlier entry on the planned CS lab computer outage for timing details.
 


:'''MH 316/322''' (CS Masters Lab & MSSI Lab) will be closed November 7, 2026. Please see the earlier entry on the planned CS lab computer outage for timing details.

 

== {{red|AUDIO/VISUAL (A/V) OUTAGES}} ==
:None at this time.

[[Category:All]]

Notices

2026-10-16T14:09:54Z

Steve410: /* PLANNED CS IT SERVICE OUTAGES */

== {{red|CS IT STAFF AVAILABILITY}} ==

* The CS IT Support staff operates out of Malone Hall. Our group is working a hybrid schedule with some of us working remotely on certain days, while others of our team are on campus.
* We are available M-F, 8:30 to 5pm, but there may be certain times we might be online only.
* Therefore, please remember to email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for assistance.
* Also, please have [https://support.cs.jhu.edu/wiki/Zoom Zoom] available on your device(s), so that we can arrange to contact you using that method, as an alternative to in-person communication.
* Steve DeBlasio, our accounts liaison, is providing a virtual version of his daily office hours for accounts, etc. Email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for details.

 



== {{red|CS IT SERVICE OUTAGES (Unplanned & Planned)}} ==

=== UNPLANNED CS IT SERVICE OUTAGES ===

:None at this time.
 

=== PLANNED CS IT SERVICE OUTAGES ===


====CS Lab Computers ''Un''available and Labs To Be ''Closed'' Due To ACM Contest Event====

:'''WHAT:''' The 1st floor CS Ugrad Lab, MH-122, and the 3rd floor CS Masters/MSSI Lab, MH 316/322 will be closed due to an upcoming ACM Programming Contest. Additionally '''ALL''' of our Linux computers that are located in the CS labs (masters1 through masters4 & ugrad1 through ugrad12) will also be ''un''available as well during that time due to the ACM Programming Contest.

:'''WHEN:'''
:: Masters & Ugrad lab Linux systems unavailable starting 5pm, Friday, November 6 and lasting through 9pm on Saturday, November 7.
:: Labs physically unavailable starting 6am Saturday, November 7 through 11pm that same evening.

:'''DETAILS'''

:Although these labs will be closed and the lab computers will be unavailable, you may still remotely access (via ssh) our Grad and Ugrad Linux compute servers that include:

:: gradv.cs.jhu.edu
:: gradx.cs.jhu.edu
:: gradz.cs.jhu.edu

:: ugradv.cs.jhu.edu
:: ugradx.cs.jhu.edu
:: ugradz.cs.jhu.edu

:For a list of our various systems (including our remotely available gradv, gradx, gradz, ugradv, ugradx, & ugradz Linux systems), please see:

::[[Linux_Clients_on_the_CS_Undergrad_Net]]

:::or

::[[Linux_Clients_on_the_CS_Grad/Research_Net]]

:We have to take down the lab systems late that Friday afternoon. At the end of the ACM contest that Saturday night, the coordinators of the contest will be turning our lab computer systems back on. Most should boot normally. But, if some do not, just trying using an alternate one in the lab. (And remember, our compute servers, referenced above, will continue to be available remotely.) We'll be back onsite the Monday afterwards and can check on any systems that didn't boot normally.

:'''NOTE: '''The printers in MH 122 and MH 316/322 will remain online, but, please pick up your printouts outside of the contest hours.


 

== {{red|CS COMPUTING LAB AVAILABILITY}} ==




:'''MH 122''' (CS Undergrad Lab/Collaboration room) will be closed November 7, 2026. Please see the earlier entry on the planned CS lab computer outage for timing details.
 


:'''MH 316/322''' (CS Masters Lab & MSSI Lab) will be closed November 7, 2026. Please see the earlier entry on the planned CS lab computer outage for timing details.

 

== {{red|AUDIO/VISUAL (A/V) OUTAGES}} ==
:None at this time.

[[Category:All]]

Notices

2026-10-16T14:08:56Z

Steve410: /* {{red|CS COMPUTING LAB AVAILABILITY}} */

== {{red|CS IT STAFF AVAILABILITY}} ==

* The CS IT Support staff operates out of Malone Hall. Our group is working a hybrid schedule with some of us working remotely on certain days, while others of our team are on campus.
* We are available M-F, 8:30 to 5pm, but there may be certain times we might be online only.
* Therefore, please remember to email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for assistance.
* Also, please have [https://support.cs.jhu.edu/wiki/Zoom Zoom] available on your device(s), so that we can arrange to contact you using that method, as an alternative to in-person communication.
* Steve DeBlasio, our accounts liaison, is providing a virtual version of his daily office hours for accounts, etc. Email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for details.

 



== {{red|CS IT SERVICE OUTAGES (Unplanned & Planned)}} ==

=== UNPLANNED CS IT SERVICE OUTAGES ===

:None at this time.
 

=== PLANNED CS IT SERVICE OUTAGES ===


====CS Lab Computers ''Un''available and Labs To Be ''Closed'' Due To ACM Contest Event====

:'''WHAT:''' The 1st floor CS Ugrad Lab, MH-122, and the 3rd floor CS Masters/MSSI Lab, MH 316/322 will be closed due to an upcoming ACM Programming Contest. Additionally '''ALL''' of our Linux computers that are located in the CS labs (masters1 through masters4 & ugrad1 through ugrad12) will also be ''un''available as well during that time due to the ACM Programming Contest.

:'''WHEN:''' Masters & Ugrad lab Linux systems unavailable starting 5pm, Friday, November 6 and lasting through 9pm on Saturday, November 7. Labs physically unavailable starting 6am Saturday, November 7 through 11pm that same evening.

:'''DETAILS'''

:Although these labs will be closed and the lab computers will be unavailable, you may still remotely access (via ssh) our Grad and Ugrad Linux compute servers that include:

:: gradv.cs.jhu.edu
:: gradx.cs.jhu.edu
:: gradz.cs.jhu.edu

:: ugradv.cs.jhu.edu
:: ugradx.cs.jhu.edu
:: ugradz.cs.jhu.edu

:For a list of our various systems (including our remotely available gradv, gradx, gradz, ugradv, ugradx, & ugradz Linux systems), please see:

::[[Linux_Clients_on_the_CS_Undergrad_Net]]

:::or

::[[Linux_Clients_on_the_CS_Grad/Research_Net]]

:We have to take down the lab systems late that Friday afternoon. At the end of the ACM contest that Saturday night, the coordinators of the contest will be turning our lab computer systems back on. Most should boot normally. But, if some do not, just trying using an alternate one in the lab. (And remember, our compute servers, referenced above, will continue to be available remotely.) We'll be back onsite the Monday afterwards and can check on any systems that didn't boot normally.

:'''NOTE: '''The printers in MH 122 and MH 316/322 will remain online, but, please pick up your printouts outside of the contest hours.


 

== {{red|CS COMPUTING LAB AVAILABILITY}} ==




:'''MH 122''' (CS Undergrad Lab/Collaboration room) will be closed November 7, 2026. Please see the earlier entry on the planned CS lab computer outage for timing details.
 


:'''MH 316/322''' (CS Masters Lab & MSSI Lab) will be closed November 7, 2026. Please see the earlier entry on the planned CS lab computer outage for timing details.

 

== {{red|AUDIO/VISUAL (A/V) OUTAGES}} ==
:None at this time.

[[Category:All]]

Notices

2026-10-16T14:07:37Z

Steve410: /* {{red|CS COMPUTING LAB AVAILABILITY}} */

== {{red|CS IT STAFF AVAILABILITY}} ==

* The CS IT Support staff operates out of Malone Hall. Our group is working a hybrid schedule with some of us working remotely on certain days, while others of our team are on campus.
* We are available M-F, 8:30 to 5pm, but there may be certain times we might be online only.
* Therefore, please remember to email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for assistance.
* Also, please have [https://support.cs.jhu.edu/wiki/Zoom Zoom] available on your device(s), so that we can arrange to contact you using that method, as an alternative to in-person communication.
* Steve DeBlasio, our accounts liaison, is providing a virtual version of his daily office hours for accounts, etc. Email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for details.

 



== {{red|CS IT SERVICE OUTAGES (Unplanned & Planned)}} ==

=== UNPLANNED CS IT SERVICE OUTAGES ===

:None at this time.
 

=== PLANNED CS IT SERVICE OUTAGES ===


====CS Lab Computers ''Un''available and Labs To Be ''Closed'' Due To ACM Contest Event====

:'''WHAT:''' The 1st floor CS Ugrad Lab, MH-122, and the 3rd floor CS Masters/MSSI Lab, MH 316/322 will be closed due to an upcoming ACM Programming Contest. Additionally '''ALL''' of our Linux computers that are located in the CS labs (masters1 through masters4 & ugrad1 through ugrad12) will also be ''un''available as well during that time due to the ACM Programming Contest.

:'''WHEN:''' Masters & Ugrad lab Linux systems unavailable starting 5pm, Friday, November 6 and lasting through 9pm on Saturday, November 7. Labs physically unavailable starting 6am Saturday, November 7 through 11pm that same evening.

:'''DETAILS'''

:Although these labs will be closed and the lab computers will be unavailable, you may still remotely access (via ssh) our Grad and Ugrad Linux compute servers that include:

:: gradv.cs.jhu.edu
:: gradx.cs.jhu.edu
:: gradz.cs.jhu.edu

:: ugradv.cs.jhu.edu
:: ugradx.cs.jhu.edu
:: ugradz.cs.jhu.edu

:For a list of our various systems (including our remotely available gradv, gradx, gradz, ugradv, ugradx, & ugradz Linux systems), please see:

::[[Linux_Clients_on_the_CS_Undergrad_Net]]

:::or

::[[Linux_Clients_on_the_CS_Grad/Research_Net]]

:We have to take down the lab systems late that Friday afternoon. At the end of the ACM contest that Saturday night, the coordinators of the contest will be turning our lab computer systems back on. Most should boot normally. But, if some do not, just trying using an alternate one in the lab. (And remember, our compute servers, referenced above, will continue to be available remotely.) We'll be back onsite the Monday afterwards and can check on any systems that didn't boot normally.

:'''NOTE: '''The printers in MH 122 and MH 316/322 will remain online, but, please pick up your printouts outside of the contest hours.


 

== {{red|CS COMPUTING LAB AVAILABILITY}} ==




:Lab will be closed November 7, 2026. Please see the earlier entry on the planned CS lab computer outage for details.
 


:Lab will be closed November 7, 2026. Please see the earlier entry on the planned CS lab computer outage for details.

 

== {{red|AUDIO/VISUAL (A/V) OUTAGES}} ==
:None at this time.

[[Category:All]]

Notices

2026-10-16T14:06:09Z

Steve410: /* PLANNED CS IT SERVICE OUTAGES */

== {{red|CS IT STAFF AVAILABILITY}} ==

* The CS IT Support staff operates out of Malone Hall. Our group is working a hybrid schedule with some of us working remotely on certain days, while others of our team are on campus.
* We are available M-F, 8:30 to 5pm, but there may be certain times we might be online only.
* Therefore, please remember to email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for assistance.
* Also, please have [https://support.cs.jhu.edu/wiki/Zoom Zoom] available on your device(s), so that we can arrange to contact you using that method, as an alternative to in-person communication.
* Steve DeBlasio, our accounts liaison, is providing a virtual version of his daily office hours for accounts, etc. Email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for details.

 



== {{red|CS IT SERVICE OUTAGES (Unplanned & Planned)}} ==

=== UNPLANNED CS IT SERVICE OUTAGES ===

:None at this time.
 

=== PLANNED CS IT SERVICE OUTAGES ===


====CS Lab Computers ''Un''available and Labs To Be ''Closed'' Due To ACM Contest Event====

:'''WHAT:''' The 1st floor CS Ugrad Lab, MH-122, and the 3rd floor CS Masters/MSSI Lab, MH 316/322 will be closed due to an upcoming ACM Programming Contest. Additionally '''ALL''' of our Linux computers that are located in the CS labs (masters1 through masters4 & ugrad1 through ugrad12) will also be ''un''available as well during that time due to the ACM Programming Contest.

:'''WHEN:''' Masters & Ugrad lab Linux systems unavailable starting 5pm, Friday, November 6 and lasting through 9pm on Saturday, November 7. Labs physically unavailable starting 6am Saturday, November 7 through 11pm that same evening.

:'''DETAILS'''

:Although these labs will be closed and the lab computers will be unavailable, you may still remotely access (via ssh) our Grad and Ugrad Linux compute servers that include:

:: gradv.cs.jhu.edu
:: gradx.cs.jhu.edu
:: gradz.cs.jhu.edu

:: ugradv.cs.jhu.edu
:: ugradx.cs.jhu.edu
:: ugradz.cs.jhu.edu

:For a list of our various systems (including our remotely available gradv, gradx, gradz, ugradv, ugradx, & ugradz Linux systems), please see:

::[[Linux_Clients_on_the_CS_Undergrad_Net]]

:::or

::[[Linux_Clients_on_the_CS_Grad/Research_Net]]

:We have to take down the lab systems late that Friday afternoon. At the end of the ACM contest that Saturday night, the coordinators of the contest will be turning our lab computer systems back on. Most should boot normally. But, if some do not, just trying using an alternate one in the lab. (And remember, our compute servers, referenced above, will continue to be available remotely.) We'll be back onsite the Monday afterwards and can check on any systems that didn't boot normally.

:'''NOTE: '''The printers in MH 122 and MH 316/322 will remain online, but, please pick up your printouts outside of the contest hours.


 

== {{red|CS COMPUTING LAB AVAILABILITY}} ==




 


Lab will be closed November 7, 2026. Please see the entry earlier on this page for Planned computer outage.

 

== {{red|AUDIO/VISUAL (A/V) OUTAGES}} ==
:None at this time.

[[Category:All]]

Notices

2026-10-16T14:05:20Z

Steve410: /* {{red|CS COMPUTING LAB AVAILABILITY}} */

== {{red|CS IT STAFF AVAILABILITY}} ==

* The CS IT Support staff operates out of Malone Hall. Our group is working a hybrid schedule with some of us working remotely on certain days, while others of our team are on campus.
* We are available M-F, 8:30 to 5pm, but there may be certain times we might be online only.
* Therefore, please remember to email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for assistance.
* Also, please have [https://support.cs.jhu.edu/wiki/Zoom Zoom] available on your device(s), so that we can arrange to contact you using that method, as an alternative to in-person communication.
* Steve DeBlasio, our accounts liaison, is providing a virtual version of his daily office hours for accounts, etc. Email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for details.

 



== {{red|CS IT SERVICE OUTAGES (Unplanned & Planned)}} ==

=== UNPLANNED CS IT SERVICE OUTAGES ===

:None at this time.
 

=== PLANNED CS IT SERVICE OUTAGES ===


====CS Lab Computers ''Un''available and Labs To Be ''Closed'' Due To ACM Contest Event====

'''WHAT:''' The 1st floor CS Ugrad Lab, MH-122, and the 3rd floor CS Masters/MSSI Lab, MH 316/322 will be closed due to an upcoming ACM Programming Contest. Additionally '''ALL''' of our Linux computers that are located in the CS labs (masters1 through masters4 & ugrad1 through ugrad12) will also be ''un''available as well during that time due to the ACM Programming Contest.

'''WHEN:''' Masters & Ugrad lab Linux systems unavailable starting 5pm, Friday, November 6 and lasting through 9pm on Saturday, November 7. Labs physically unavailable starting 6am Saturday, November 7 through 11pm that same evening.

'''DETAILS'''

Although these labs will be closed and the lab computers will be unavailable, you may still remotely access (via ssh) our Grad and Ugrad Linux compute servers that include:

:: gradv.cs.jhu.edu
:: gradx.cs.jhu.edu
:: gradz.cs.jhu.edu

:: ugradv.cs.jhu.edu
:: ugradx.cs.jhu.edu
:: ugradz.cs.jhu.edu

For a list of our various systems (including our remotely available gradv, gradx, gradz, ugradv, ugradx, & ugradz Linux systems), please see:

[[Linux_Clients_on_the_CS_Undergrad_Net]]

:or

[[Linux_Clients_on_the_CS_Grad/Research_Net]]

We have to take down the lab systems late that Friday afternoon. At the end of the ACM contest that Saturday night, the coordinators of the contest will be turning our lab computer systems back on. Most should boot normally. But, if some do not, just trying using an alternate one in the lab. (And remember, our compute servers, referenced above, will continue to be available remotely.) We'll be back onsite the Monday afterwards and can check on any systems that didn't boot normally.

'''NOTE: '''The printers in MH 122 and MH 316/322 will remain online, but, please pick up your printouts outside of the contest hours.


 

== {{red|CS COMPUTING LAB AVAILABILITY}} ==




 


Lab will be closed November 7, 2026. Please see the entry earlier on this page for Planned computer outage.

 

== {{red|AUDIO/VISUAL (A/V) OUTAGES}} ==
:None at this time.

[[Category:All]]

Notices

2026-10-16T14:03:48Z

Steve410: /* CS Lab Computers Unavailable and Labs To Be Closed Due To ACM Contest Event */

== {{red|CS IT STAFF AVAILABILITY}} ==

* The CS IT Support staff operates out of Malone Hall. Our group is working a hybrid schedule with some of us working remotely on certain days, while others of our team are on campus.
* We are available M-F, 8:30 to 5pm, but there may be certain times we might be online only.
* Therefore, please remember to email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for assistance.
* Also, please have [https://support.cs.jhu.edu/wiki/Zoom Zoom] available on your device(s), so that we can arrange to contact you using that method, as an alternative to in-person communication.
* Steve DeBlasio, our accounts liaison, is providing a virtual version of his daily office hours for accounts, etc. Email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for details.

 



== {{red|CS IT SERVICE OUTAGES (Unplanned & Planned)}} ==

=== UNPLANNED CS IT SERVICE OUTAGES ===

:None at this time.
 

=== PLANNED CS IT SERVICE OUTAGES ===


====CS Lab Computers ''Un''available and Labs To Be ''Closed'' Due To ACM Contest Event====

'''WHAT:''' The 1st floor CS Ugrad Lab, MH-122, and the 3rd floor CS Masters/MSSI Lab, MH 316/322 will be closed due to an upcoming ACM Programming Contest. Additionally '''ALL''' of our Linux computers that are located in the CS labs (masters1 through masters4 & ugrad1 through ugrad12) will also be ''un''available as well during that time due to the ACM Programming Contest.

'''WHEN:''' Masters & Ugrad lab Linux systems unavailable starting 5pm, Friday, November 6 and lasting through 9pm on Saturday, November 7. Labs physically unavailable starting 6am Saturday, November 7 through 11pm that same evening.

'''DETAILS'''

Although these labs will be closed and the lab computers will be unavailable, you may still remotely access (via ssh) our Grad and Ugrad Linux compute servers that include:

:: gradv.cs.jhu.edu
:: gradx.cs.jhu.edu
:: gradz.cs.jhu.edu

:: ugradv.cs.jhu.edu
:: ugradx.cs.jhu.edu
:: ugradz.cs.jhu.edu

For a list of our various systems (including our remotely available gradv, gradx, gradz, ugradv, ugradx, & ugradz Linux systems), please see:

[[Linux_Clients_on_the_CS_Undergrad_Net]]

:or

[[Linux_Clients_on_the_CS_Grad/Research_Net]]

We have to take down the lab systems late that Friday afternoon. At the end of the ACM contest that Saturday night, the coordinators of the contest will be turning our lab computer systems back on. Most should boot normally. But, if some do not, just trying using an alternate one in the lab. (And remember, our compute servers, referenced above, will continue to be available remotely.) We'll be back onsite the Monday afterwards and can check on any systems that didn't boot normally.

'''NOTE: '''The printers in MH 122 and MH 316/322 will remain online, but, please pick up your printouts outside of the contest hours.


 

== {{red|CS COMPUTING LAB AVAILABILITY}} ==



:'''MH 122''' (CS Undergrad Lab/Collaboration room) is available for in-person access.
 

:'''MH 316/322''' (CS Masters Lab & MSSI Lab) is available for in-person access.

 

== {{red|AUDIO/VISUAL (A/V) OUTAGES}} ==
:None at this time.

[[Category:All]]

Notices

2026-10-16T14:03:33Z

Steve410: /* CS Lab Computers Unavailable and Labs To Be Closed Due To ACM Contest Event */

== {{red|CS IT STAFF AVAILABILITY}} ==

* The CS IT Support staff operates out of Malone Hall. Our group is working a hybrid schedule with some of us working remotely on certain days, while others of our team are on campus.
* We are available M-F, 8:30 to 5pm, but there may be certain times we might be online only.
* Therefore, please remember to email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for assistance.
* Also, please have [https://support.cs.jhu.edu/wiki/Zoom Zoom] available on your device(s), so that we can arrange to contact you using that method, as an alternative to in-person communication.
* Steve DeBlasio, our accounts liaison, is providing a virtual version of his daily office hours for accounts, etc. Email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for details.

 



== {{red|CS IT SERVICE OUTAGES (Unplanned & Planned)}} ==

=== UNPLANNED CS IT SERVICE OUTAGES ===

:None at this time.
 

=== PLANNED CS IT SERVICE OUTAGES ===


====CS Lab Computers ''Un''available and Labs To Be ''Closed'' Due To ACM Contest Event====

'''WHAT:''' The 1st floor CS Ugrad Lab, MH-122, and the 3rd floor CS Masters/MSSI Lab, MH 316/322 will be closed due to an upcoming ACM Programming Contest. Additionally '''ALL''' of our Linux computers that are located in the CS labs (masters1 through masters4 & ugrad1 through ugrad12) will also be ''un''available as well during that time due to the ACM Programming Contest.

'''WHEN:''' Masters & Ugrad lab Linux systems unavailable starting 5pm, Friday, November 6 and lasting through 9pm on Saturday, November 7. Labs physically unavailable starting 6am Saturday, November 7 through 11pm that same evening.

'''DETAILS'''

Although these labs will be closed and the lab computers will be unavailable, you may still remotely access (via ssh) our Grad and Ugrad Linux compute servers that include:

:: gradv.cs.jhu.edu
:: gradx.cs.jhu.edu
:: gradz.cs.jhu.edu

:: ugradv.cs.jhu.edu
:: ugradx.cs.jhu.edu
:: ugradz.cs.jhu.edu

For a list of our various systems (including our remotely available gradv, gradx, gradz, ugradv, ugradx, & ugradz Linux systems), please see:

[[Linux_Clients_on_the_CS_Undergrad_Net]]

:or

[[Linux_Clients_on_the_CS_Grad/Research_Net]]

We have to take down the lab systems late that Friday afternoon. At the end of the ACM contest that Saturday night, the coordinators of the contest will be turning our lab computer systems back on. Most should boot normally. But, if some do not, just trying using an alternate one in the lab. (And remember, our compute servers, referenced above, will continue to be available remotely.) We'll be back onsite the Monday afterwards and can check on any systems that didn't boot normally.

'''NOTE:'''The printers in MH 122 and MH 316/322 will remain online, but, please pick up your printouts outside of the contest hours.


 

== {{red|CS COMPUTING LAB AVAILABILITY}} ==



:'''MH 122''' (CS Undergrad Lab/Collaboration room) is available for in-person access.
 

:'''MH 316/322''' (CS Masters Lab & MSSI Lab) is available for in-person access.

 

== {{red|AUDIO/VISUAL (A/V) OUTAGES}} ==
:None at this time.

[[Category:All]]

Notices

2026-10-16T14:02:55Z

Steve410: /* PLANNED CS IT SERVICE OUTAGES */

== {{red|CS IT STAFF AVAILABILITY}} ==

* The CS IT Support staff operates out of Malone Hall. Our group is working a hybrid schedule with some of us working remotely on certain days, while others of our team are on campus.
* We are available M-F, 8:30 to 5pm, but there may be certain times we might be online only.
* Therefore, please remember to email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for assistance.
* Also, please have [https://support.cs.jhu.edu/wiki/Zoom Zoom] available on your device(s), so that we can arrange to contact you using that method, as an alternative to in-person communication.
* Steve DeBlasio, our accounts liaison, is providing a virtual version of his daily office hours for accounts, etc. Email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for details.

 



== {{red|CS IT SERVICE OUTAGES (Unplanned & Planned)}} ==

=== UNPLANNED CS IT SERVICE OUTAGES ===

:None at this time.
 

=== PLANNED CS IT SERVICE OUTAGES ===


====CS Lab Computers ''Un''available and Labs To Be ''Closed'' Due To ACM Contest Event====

'''WHAT:''' The 1st floor CS Ugrad Lab, MH-122, and the 3rd floor CS Masters/MSSI Lab, MH 316/322 will be closed due to an upcoming ACM Programming Contest. Additionally '''ALL''' of our Linux computers that are located in the CS labs (masters1 through masters4 & ugrad1 through ugrad12) will also be unavailable as well during that time due to the ACM Programming Contest.

'''WHEN:''' Masters & Ugrad lab Linux systems unavailable starting 5pm, Friday, November 6 and lasting through 9pm on Saturday, November 7. Labs physically unavailable starting 6am Saturday, November 7 through 11pm that same evening.

'''DETAILS'''

Although these labs will be closed and the lab computers will be unavailable, you may still remotely access (via ssh) our Grad and Ugrad Linux compute servers that include:

:: gradv.cs.jhu.edu
:: gradx.cs.jhu.edu
:: gradz.cs.jhu.edu

:: ugradv.cs.jhu.edu
:: ugradx.cs.jhu.edu
:: ugradz.cs.jhu.edu

For a list of our various systems (including our remotely available gradv, gradx, gradz, ugradv, ugradx, & ugradz Linux systems), please see:

[[Linux_Clients_on_the_CS_Undergrad_Net]]

:or

[[Linux_Clients_on_the_CS_Grad/Research_Net]]

We have to take down the lab systems late that Friday afternoon. At the end of the ACM contest that Saturday night, the coordinators of the contest will be turning our lab computer systems back on. Most should boot normally. But, if some do not, just trying using an alternate one in the lab. (And remember, our compute servers, referenced above, will continue to be available remotely.) We'll be back onsite the Monday afterwards and can check on any systems that didn't boot normally.

'''NOTE:'''The printers in MH 122 and MH 316/322 will remain online, but, please pick up your printouts outside of the contest hours.


 

== {{red|CS COMPUTING LAB AVAILABILITY}} ==



:'''MH 122''' (CS Undergrad Lab/Collaboration room) is available for in-person access.
 

:'''MH 316/322''' (CS Masters Lab & MSSI Lab) is available for in-person access.

 

== {{red|AUDIO/VISUAL (A/V) OUTAGES}} ==
:None at this time.

[[Category:All]]

Notices

2026-10-16T14:01:13Z

Steve410: /* PLANNED CS IT SERVICE OUTAGES */

== {{red|CS IT STAFF AVAILABILITY}} ==

* The CS IT Support staff operates out of Malone Hall. Our group is working a hybrid schedule with some of us working remotely on certain days, while others of our team are on campus.
* We are available M-F, 8:30 to 5pm, but there may be certain times we might be online only.
* Therefore, please remember to email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for assistance.
* Also, please have [https://support.cs.jhu.edu/wiki/Zoom Zoom] available on your device(s), so that we can arrange to contact you using that method, as an alternative to in-person communication.
* Steve DeBlasio, our accounts liaison, is providing a virtual version of his daily office hours for accounts, etc. Email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for details.

 



== {{red|CS IT SERVICE OUTAGES (Unplanned & Planned)}} ==

=== UNPLANNED CS IT SERVICE OUTAGES ===

:None at this time.
 

=== PLANNED CS IT SERVICE OUTAGES ===


====CS Lab Computers Unavailable and Labs Closure Due To ACM Contest Event====

'''WHAT:''' The 1st floor CS Ugrad Lab, MH-122, and the 3rd floor CS Masters/MSSI Lab, MH 316/322 will be closed due to an upcoming ACM Programming Contest. Additionally *ALL* of our Linux computers that are located in the CS labs (masters1 through masters4 & ugrad1 through ugrad12) will also be unavailable as well during that time due to the ACM Programming Contest.

'''WHEN:''' Masters & Ugrad lab Linux systems unavailable starting 5pm, Friday, November 6 and lasting through 9pm on Saturday, November 7. Labs physically unavailable starting 6am Saturday, November 7 through 11pm that same evening.

'''DETAILS'''

Although these labs will be closed and the lab computers will be unavailable, you may still remotely access (via ssh) our Grad and Ugrad Linux compute servers that include:

:: gradv.cs.jhu.edu
:: gradx.cs.jhu.edu
:: gradz.cs.jhu.edu

:: ugradv.cs.jhu.edu
:: ugradx.cs.jhu.edu
:: ugradz.cs.jhu.edu

For a list of our various systems (including our remotely available gradv, gradx, gradz, ugradv, ugradx, & ugradz Linux systems), please see:

[[Linux_Clients_on_the_CS_Undergrad_Net]]

:or

[[Linux_Clients_on_the_CS_Grad/Research_Net]]

We have to take down the lab systems late that Friday afternoon. At the end of the ACM contest that Saturday night, the coordinators of the contest will be turning our lab computer systems back on. Most should boot normally. But, if some do not, just trying using an alternate one in the lab. (And remember, our compute servers, referenced above, will continue to be available remotely.) We'll be back onsite the Monday afterwards and can check on any systems that didn't boot normally.

'''NOTE:'''The printers in MH 122 and MH 316/322 will remain online, but, please pick up your printouts outside of the contest hours.


 

== {{red|CS COMPUTING LAB AVAILABILITY}} ==



:'''MH 122''' (CS Undergrad Lab/Collaboration room) is available for in-person access.
 

:'''MH 316/322''' (CS Masters Lab & MSSI Lab) is available for in-person access.

 

== {{red|AUDIO/VISUAL (A/V) OUTAGES}} ==
:None at this time.

[[Category:All]]

Notices

2026-10-16T13:59:33Z

Steve410: /* PLANNED CS IT SERVICE OUTAGES */

== {{red|CS IT STAFF AVAILABILITY}} ==

* The CS IT Support staff operates out of Malone Hall. Our group is working a hybrid schedule with some of us working remotely on certain days, while others of our team are on campus.
* We are available M-F, 8:30 to 5pm, but there may be certain times we might be online only.
* Therefore, please remember to email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for assistance.
* Also, please have [https://support.cs.jhu.edu/wiki/Zoom Zoom] available on your device(s), so that we can arrange to contact you using that method, as an alternative to in-person communication.
* Steve DeBlasio, our accounts liaison, is providing a virtual version of his daily office hours for accounts, etc. Email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for details.

 



== {{red|CS IT SERVICE OUTAGES (Unplanned & Planned)}} ==

=== UNPLANNED CS IT SERVICE OUTAGES ===

:None at this time.
 

=== PLANNED CS IT SERVICE OUTAGES ===


'''WHAT:''' The 1st floor CS Ugrad Lab, MH-122, and the 3rd floor CS Masters/MSSI Lab, MH 316/322 will be closed due to an upcoming ACM Programming Contest. Additionally *ALL* of our Linux computers that are located in the CS labs (masters1 through masters4 & ugrad1 through ugrad12) will also be unavailable as well during that time due to the ACM Programming Contest.

'''WHEN:''' Masters & Ugrad lab Linux systems unavailable starting 5pm, Friday, November 6 and lasting through 9pm on Saturday, November 7. Labs physically unavailable starting 6am Saturday, November 7 through 11pm that same evening.

'''DETAILS'''

Although these labs will be closed and the lab computers will be unavailable, you may still remotely access (via ssh) our Grad and Ugrad Linux compute servers that include:

:: gradv.cs.jhu.edu
:: gradx.cs.jhu.edu
:: gradz.cs.jhu.edu

:: ugradv.cs.jhu.edu
:: ugradx.cs.jhu.edu
:: ugradz.cs.jhu.edu

For a list of our various systems (including our remotely available gradv, gradx, gradz, ugradv, ugradx, & ugradz Linux systems), please see:

[[Linux_Clients_on_the_CS_Undergrad_Net]]

:or

[[Linux_Clients_on_the_CS_Grad/Research_Net]]

We have to take down the lab systems late that Friday afternoon. At the end of the ACM contest that Saturday night, the coordinators of the contest will be turning our lab computer systems back on. Most should boot normally. But, if some do not, just trying using an alternate one in the lab. (And remember, our compute servers, referenced above, will continue to be available remotely.) We'll be back onsite the Monday afterwards and can check on any systems that didn't boot normally.

'''NOTE:'''The printers in MH 122 and MH 316/322 will remain online, but, please pick up your printouts outside of the contest hours.


 

== {{red|CS COMPUTING LAB AVAILABILITY}} ==



:'''MH 122''' (CS Undergrad Lab/Collaboration room) is available for in-person access.
 

:'''MH 316/322''' (CS Masters Lab & MSSI Lab) is available for in-person access.

 

== {{red|AUDIO/VISUAL (A/V) OUTAGES}} ==
:None at this time.

[[Category:All]]

Notices

2026-10-16T13:59:13Z

Steve410: /* PLANNED CS IT SERVICE OUTAGES */

== {{red|CS IT STAFF AVAILABILITY}} ==

* The CS IT Support staff operates out of Malone Hall. Our group is working a hybrid schedule with some of us working remotely on certain days, while others of our team are on campus.
* We are available M-F, 8:30 to 5pm, but there may be certain times we might be online only.
* Therefore, please remember to email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for assistance.
* Also, please have [https://support.cs.jhu.edu/wiki/Zoom Zoom] available on your device(s), so that we can arrange to contact you using that method, as an alternative to in-person communication.
* Steve DeBlasio, our accounts liaison, is providing a virtual version of his daily office hours for accounts, etc. Email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for details.

 



== {{red|CS IT SERVICE OUTAGES (Unplanned & Planned)}} ==

=== UNPLANNED CS IT SERVICE OUTAGES ===

:None at this time.
 

=== PLANNED CS IT SERVICE OUTAGES ===


'''WHAT:''' The 1st floor CS Ugrad Lab, MH-122, and the 3rd floor CS Masters/MSSI Lab, MH 316/322 will be closed due to an upcoming ACM Programming Contest. Additionally *ALL* of our Linux computers that are located in the CS labs (masters1 through masters4 & ugrad1 through ugrad12) will also be unavailable as well during that time due to the ACM Programming Contest.

'''WHEN:''' Masters & Ugrad lab Linux systems unavailable starting 5pm, Friday, November 6 and lasting through 9pm on Saturday, November 7. Labs physically unavailable starting 6am Saturday, November 7 through 11pm that same evening.

'''DETAILS'''

Although these labs will be closed and the lab computers will be unavailable, you may still remotely access (via ssh) our Grad and Ugrad Linux compute servers that include:

:: gradv.cs.jhu.edu
:: gradx.cs.jhu.edu
:: gradz.cs.jhu.edu

:: ugradv.cs.jhu.edu
:: ugradx.cs.jhu.edu
:: ugradz.cs.jhu.edu

For a list of our various systems (including our remotely available gradv, gradx, gradz, ugradv, ugradx, & ugradz Linux systems), please see:

[[Linux_Clients_on_the_CS_Undergrad_Net]]

or

[[Linux_Clients_on_the_CS_Grad/Research_Net]]

We have to take down the lab systems late that Friday afternoon. At the end of the ACM contest that Saturday night, the coordinators of the contest will be turning our lab computer systems back on. Most should boot normally. But, if some do not, just trying using an alternate one in the lab. (And remember, our compute servers, referenced above, will continue to be available remotely.) We'll be back onsite the Monday afterwards and can check on any systems that didn't boot normally.

'''NOTE:'''The printers in MH 122 and MH 316/322 will remain online, but, please pick up your printouts outside of the contest hours.


 

== {{red|CS COMPUTING LAB AVAILABILITY}} ==



:'''MH 122''' (CS Undergrad Lab/Collaboration room) is available for in-person access.
 

:'''MH 316/322''' (CS Masters Lab & MSSI Lab) is available for in-person access.

 

== {{red|AUDIO/VISUAL (A/V) OUTAGES}} ==
:None at this time.

[[Category:All]]

Mapping CS Home Directories Using SAMBA (SMB)

2026-10-12T15:27:24Z

Steve410: /* Windows 11 */

== Intro to Samba ==

[http://www.samba.org Samba], as used in the Computer Science Department, is a method of mapping the department's Grad Net user home directories (residing on our Linux-based home directory file server) to Windows, MacOS, and Linux-based computers over the network. Basically, you can map your Linux home directory to, for example, some lettered drive on your Windows system. (The actual protocol used is called ''SMB'', which stands for ''Server Message Block''. You may also see or hear it as the term SMB/CIFS.)

As an example, on our CS Grad Network, a home directory such as <code>/users/mary</code> can be mapped onto a Windows system as drive H: or drive M: or whatever drive letter is available. The drive letter used is arbitrary.

== ''Who'' Can Use This Capability in CS to Map Their CS Linux Home Directory? ==

This feature is currently available to anyone with a [https://support.cs.jhu.edu/wiki/Obtaining_CS_Computer_Accounts '''''CS Grad Net''' Linux account''].

:'''''NOTE:''''' If your Grad Net Linux account was created ''before'' July 2018, you ''might'' need to [[How To Reset Your Password|have your CS password reset]] before you can use Samba for the first time. So, try mapping the directory first, and if you are unable to map your home directory using the below instructions, you will most likely need to have us reset your password (even if you can log in to our Linux systems without problems.)

== How to Map Your CS Grad Net Home Linux Directory Using Samba ==

* Make sure your system resides somewhere on the JHU network. You must have a JHU-based IP (plugged in network, Hopkins Wifi, VPN, etc.)

* If your system is outside of JHU, then you need to first become part of [https://support.cs.jhu.edu/wiki/VPN_-_JHU JHU's VPN] service.

* On your Windows, Mac, or Linux system, use its appropriate drive mapping command/configuration to map your ''CS home directory''. In the case of your home directory, the share name will be the same as your Linux account name.

* You'll need the server name for the share: ''rtfm.cs.jhu.edu''

Typically, use the following mapping processes:

==Windows 11==

* In File Manager, find ''This PC'''


* Choose ''Map Network Drive''

* Choose Drive Letter from the drop-down (Remember, Drive Letter is arbitrary.)

* Enter \\''servername''\''sharename''
** in our case, you'd be entering rtfm.cs.jhu.edu as the server name. So, ''\\rtfm.cs.jhu.edu\sharename'' (where ''sharename'' is your username, for instance.)

* Decide whether you want to check off:
::Reconnect at sign-in

:::and/or

::Connect using different credentials (you need to make sure you use the credentials for accessing your Grad Net shares, which might not be the same as the login you use when you start Windows.)

::'''NOTE:''' If your windows system is on a different domain (e.g., ''WIN'' or something else) and you're having issues connecting to our CS shares, choose the ''Connect using different credentials'' option, and for username, ''pre''pend your CS username with ''csoffice\'' So, if your CS username is jane1, then you should enter ''csoffice\jane1''

*Click '''Finish'''

==MAC==

* Click on ''Finder''

* Choose ''Go''

* Choose ''Connect to Server''

* Enter ''smb:''//''servername''/''sharename''

==Linux==

:Varies depending on your desktop environment. Please search the Internet for SMB/SAMBA filesystem-mounting techniques for your flavor of Linux.

==NOTES:==

===Server Name Format===
As mentioned above, in each instance of mounting the SMB share on the CS Grad Net, the server name to use is <code>rtfm.cs.jhu.edu</code>.

e.g. in Windows:

:<code>\\rtfm.cs.jhu.edu\mary</code>
:''(notice the use of '''back''' slashes.)''

or on mac:

:<code>smb://rtfm.cs.jhu.edu/mary</code>
:''(notice the use of '''forward''' slashes.)''

[[Category:Linux Clients]]
[[Category:Accounts]]
[[Category:Misc]]
[[Category:Networking]]

Mapping CS Home Directories Using SAMBA (SMB)

2026-10-12T15:27:14Z

Steve410: /* Windows 11 */

== Intro to Samba ==

[http://www.samba.org Samba], as used in the Computer Science Department, is a method of mapping the department's Grad Net user home directories (residing on our Linux-based home directory file server) to Windows, MacOS, and Linux-based computers over the network. Basically, you can map your Linux home directory to, for example, some lettered drive on your Windows system. (The actual protocol used is called ''SMB'', which stands for ''Server Message Block''. You may also see or hear it as the term SMB/CIFS.)

As an example, on our CS Grad Network, a home directory such as <code>/users/mary</code> can be mapped onto a Windows system as drive H: or drive M: or whatever drive letter is available. The drive letter used is arbitrary.

== ''Who'' Can Use This Capability in CS to Map Their CS Linux Home Directory? ==

This feature is currently available to anyone with a [https://support.cs.jhu.edu/wiki/Obtaining_CS_Computer_Accounts '''''CS Grad Net''' Linux account''].

:'''''NOTE:''''' If your Grad Net Linux account was created ''before'' July 2018, you ''might'' need to [[How To Reset Your Password|have your CS password reset]] before you can use Samba for the first time. So, try mapping the directory first, and if you are unable to map your home directory using the below instructions, you will most likely need to have us reset your password (even if you can log in to our Linux systems without problems.)

== How to Map Your CS Grad Net Home Linux Directory Using Samba ==

* Make sure your system resides somewhere on the JHU network. You must have a JHU-based IP (plugged in network, Hopkins Wifi, VPN, etc.)

* If your system is outside of JHU, then you need to first become part of [https://support.cs.jhu.edu/wiki/VPN_-_JHU JHU's VPN] service.

* On your Windows, Mac, or Linux system, use its appropriate drive mapping command/configuration to map your ''CS home directory''. In the case of your home directory, the share name will be the same as your Linux account name.

* You'll need the server name for the share: ''rtfm.cs.jhu.edu''

Typically, use the following mapping processes:

==Windows 11==

* In File Manager, find ''This PC'''

* Choose ''Map Network Drive''

* Choose Drive Letter from the drop-down (Remember, Drive Letter is arbitrary.)

* Enter \\''servername''\''sharename''
** in our case, you'd be entering rtfm.cs.jhu.edu as the server name. So, ''\\rtfm.cs.jhu.edu\sharename'' (where ''sharename'' is your username, for instance.)

* Decide whether you want to check off:
::Reconnect at sign-in

:::and/or

::Connect using different credentials (you need to make sure you use the credentials for accessing your Grad Net shares, which might not be the same as the login you use when you start Windows.)

::'''NOTE:''' If your windows system is on a different domain (e.g., ''WIN'' or something else) and you're having issues connecting to our CS shares, choose the ''Connect using different credentials'' option, and for username, ''pre''pend your CS username with ''csoffice\'' So, if your CS username is jane1, then you should enter ''csoffice\jane1''

*Click '''Finish'''

==MAC==

* Click on ''Finder''

* Choose ''Go''

* Choose ''Connect to Server''

* Enter ''smb:''//''servername''/''sharename''

==Linux==

:Varies depending on your desktop environment. Please search the Internet for SMB/SAMBA filesystem-mounting techniques for your flavor of Linux.

==NOTES:==

===Server Name Format===
As mentioned above, in each instance of mounting the SMB share on the CS Grad Net, the server name to use is <code>rtfm.cs.jhu.edu</code>.

e.g. in Windows:

:<code>\\rtfm.cs.jhu.edu\mary</code>
:''(notice the use of '''back''' slashes.)''

or on mac:

:<code>smb://rtfm.cs.jhu.edu/mary</code>
:''(notice the use of '''forward''' slashes.)''

[[Category:Linux Clients]]
[[Category:Accounts]]
[[Category:Misc]]
[[Category:Networking]]

Mapping CS Home Directories Using SAMBA (SMB)

2026-10-12T15:26:37Z

Steve410: /* Windows 10 */

== Intro to Samba ==

[http://www.samba.org Samba], as used in the Computer Science Department, is a method of mapping the department's Grad Net user home directories (residing on our Linux-based home directory file server) to Windows, MacOS, and Linux-based computers over the network. Basically, you can map your Linux home directory to, for example, some lettered drive on your Windows system. (The actual protocol used is called ''SMB'', which stands for ''Server Message Block''. You may also see or hear it as the term SMB/CIFS.)

As an example, on our CS Grad Network, a home directory such as <code>/users/mary</code> can be mapped onto a Windows system as drive H: or drive M: or whatever drive letter is available. The drive letter used is arbitrary.

== ''Who'' Can Use This Capability in CS to Map Their CS Linux Home Directory? ==

This feature is currently available to anyone with a [https://support.cs.jhu.edu/wiki/Obtaining_CS_Computer_Accounts '''''CS Grad Net''' Linux account''].

:'''''NOTE:''''' If your Grad Net Linux account was created ''before'' July 2018, you ''might'' need to [[How To Reset Your Password|have your CS password reset]] before you can use Samba for the first time. So, try mapping the directory first, and if you are unable to map your home directory using the below instructions, you will most likely need to have us reset your password (even if you can log in to our Linux systems without problems.)

== How to Map Your CS Grad Net Home Linux Directory Using Samba ==

* Make sure your system resides somewhere on the JHU network. You must have a JHU-based IP (plugged in network, Hopkins Wifi, VPN, etc.)

* If your system is outside of JHU, then you need to first become part of [https://support.cs.jhu.edu/wiki/VPN_-_JHU JHU's VPN] service.

* On your Windows, Mac, or Linux system, use its appropriate drive mapping command/configuration to map your ''CS home directory''. In the case of your home directory, the share name will be the same as your Linux account name.

* You'll need the server name for the share: ''rtfm.cs.jhu.edu''

Typically, use the following mapping processes:

==Windows 11==

* Run '''This PC'''
** There are two ways to get to '''This PC'''
***METHOD 1:
****Run ''File Explorer''
****Choose ''This PC''
***METHOD 2:
****From Windows 10 Search bar, search and run ''This PC''

* Choose ''Map Network Drive''

* Choose Drive Letter from the drop-down (Remember, Drive Letter is arbitrary.)

* Enter \\''servername''\''sharename''
** in our case, you'd be entering rtfm.cs.jhu.edu as the server name. So, ''\\rtfm.cs.jhu.edu\sharename'' (where ''sharename'' is your username, for instance.)

* Decide whether you want to check off:
::Reconnect at sign-in

:::and/or

::Connect using different credentials (you need to make sure you use the credentials for accessing your Grad Net shares, which might not be the same as the login you use when you start Windows.)

::'''NOTE:''' If your windows system is on a different domain (e.g., ''WIN'' or something else) and you're having issues connecting to our CS shares, choose the ''Connect using different credentials'' option, and for username, ''pre''pend your CS username with ''csoffice\'' So, if your CS username is jane1, then you should enter ''csoffice\jane1''

*Click '''Finish'''

==MAC==

* Click on ''Finder''

* Choose ''Go''

* Choose ''Connect to Server''

* Enter ''smb:''//''servername''/''sharename''

==Linux==

:Varies depending on your desktop environment. Please search the Internet for SMB/SAMBA filesystem-mounting techniques for your flavor of Linux.

==NOTES:==

===Server Name Format===
As mentioned above, in each instance of mounting the SMB share on the CS Grad Net, the server name to use is <code>rtfm.cs.jhu.edu</code>.

e.g. in Windows:

:<code>\\rtfm.cs.jhu.edu\mary</code>
:''(notice the use of '''back''' slashes.)''

or on mac:

:<code>smb://rtfm.cs.jhu.edu/mary</code>
:''(notice the use of '''forward''' slashes.)''

[[Category:Linux Clients]]
[[Category:Accounts]]
[[Category:Misc]]
[[Category:Networking]]

CS Database Class (315/415/615) MySQL Information

2026-10-09T20:02:40Z

Steve410: /* IMPORTANT INFO ABOUT ACCESSING THE MYSQL SERVICE ON dbase.cs.jhu.edu */

As part of the CS Database Class (for CS315, CS415, and/or CS615), your instructor might have you utilize a special '''MySQL''' server called ''dbase.cs.jhu.edu''.

{{messagebox|'''Note 1:''' This ''dbase.cs.jhu.edu'' MySQL server ''is for the Databases class only''. It is '''''not''''' the same as the [[Dept. MySQL Server|MySQL server available to the entire department (''mysql.cs.jhu.edu'')]].|type=info}}

{{messagebox|'''Note 2 :''' You ''do not'' need a CS login account to access the MySQL service on ''dbase.cs.jhu.edu'', nor can you ''ssh'' into dbase.cs.jhu.edu. Instead, you will need a ''MySQL'' account. Please see below for details.|type=info}}

{{messagebox|'''Note 3:''' Access to the MySQL service on dbase.cs.jhu.edu is '''limited to those on a JHU-Network-based computer, including Hopkins WiFi (except JHGuesnet) or on the [[VPN_-_JHU | VPN]].'''|type=info}}

Although the CS IT group maintains the physical dbase.cs.jhu.edu server and its operating system, the Databases course's '''Teaching Assistant (TA) maintains the ''MySQL accounts'' for dbase.cs.jhu.edu'''

{{red|Therefore, ''all MySQL '''account-related/access-related''' issues and questions for dbase.cs.jhu.edu'' should go to the '''TA''' or the '''CA''' for the course, as that's the person '''responsible for creating those MySQL accounts.'''}}

==IMPORTANT INFO ABOUT ACCESSING THE MYSQL SERVICE ON dbase.cs.jhu.edu==

* Access to the MySQL service on dbase.cs.jhu.edu is '''limited to those on a JHU-Network-based computer, including Hopkins WiFi (except JHGuesnet) or on the [[VPN_-_JHU | VPN]].'''

* Your CS Linux account (Grad/Ugrad) is '''not''' the same as a CS MySQL-related account, ''even if the usernames are the same.'' Our Linux accounts and our MySQL accounts are two separate types of accounts.

* '''''You cannot ssh into dbase.cs.jhu.edu.''''' The only way you can connect to dbase.cs.jhu.edu is remotely, via a ''MySQL client''.

* If you '''already have a CS ''login'' (ssh) account''' for any of our [[:Category:Linux Clients|CS Department Linux clients]], you can log into one of those Linux systems and use its text-based MySQL client by running <kbd>mysql -h dbase.cs.jhu.edu -u <var>account</var> -p <var>database</var></kbd> , where "<var>account</var>" is your dbase.cs.jhu.edu account name and "<var>database</var>" is the name of your database. You will be prompted to enter your password.

* If you '''do not have a CS ''login'' (ssh) account ''' ''(you '''do not''' need one to access our MySQL service on dbase.cs.jhu.edu''), you can access dbase.cs.jhu.edu with any MySQL client, either text-based or GUI, and, as mentioned before, '''''from any computer on the JHU network, [[Wireless_Networking | JHU's wireless network]] (but not JHGuestnet), or [[VPN_-_JHU | VPN]].''''' Just use "dbase.cs.jhu.edu" as the hostname. If asked for a network port, use "3306". MySQL clients are available for Linux, Mac, and Windows systems.

* Those selected as being the MySQL admin for the specific course must provide us '''''at least one business day''''' to set up a new MySQL admin password for you. At that time, we'll provide you instructions on how to admin the MySQL accounts for the course.
[[Category:MySQL]]

CS Database Class (315/415/615) MySQL Information

2026-10-09T20:02:21Z

Steve410: /* IMPORTANT INFO ABOUT ACCESSING THE MYSQL SERVICE ON dbase.cs.jhu.edu */

As part of the CS Database Class (for CS315, CS415, and/or CS615), your instructor might have you utilize a special '''MySQL''' server called ''dbase.cs.jhu.edu''.

{{messagebox|'''Note 1:''' This ''dbase.cs.jhu.edu'' MySQL server ''is for the Databases class only''. It is '''''not''''' the same as the [[Dept. MySQL Server|MySQL server available to the entire department (''mysql.cs.jhu.edu'')]].|type=info}}

{{messagebox|'''Note 2 :''' You ''do not'' need a CS login account to access the MySQL service on ''dbase.cs.jhu.edu'', nor can you ''ssh'' into dbase.cs.jhu.edu. Instead, you will need a ''MySQL'' account. Please see below for details.|type=info}}

{{messagebox|'''Note 3:''' Access to the MySQL service on dbase.cs.jhu.edu is '''limited to those on a JHU-Network-based computer, including Hopkins WiFi (except JHGuesnet) or on the [[VPN_-_JHU | VPN]].'''|type=info}}

Although the CS IT group maintains the physical dbase.cs.jhu.edu server and its operating system, the Databases course's '''Teaching Assistant (TA) maintains the ''MySQL accounts'' for dbase.cs.jhu.edu'''

{{red|Therefore, ''all MySQL '''account-related/access-related''' issues and questions for dbase.cs.jhu.edu'' should go to the '''TA''' or the '''CA''' for the course, as that's the person '''responsible for creating those MySQL accounts.'''}}

==IMPORTANT INFO ABOUT ACCESSING THE MYSQL SERVICE ON dbase.cs.jhu.edu==

* Access to the MySQL service on dbase.cs.jhu.edu is '''limited to those on a JHU-Network-based computer, including Hopkins WiFi (except JHGuesnet) or on the [[VPN_-_JHU | VPN]].'''

* Your CS Linux account (Grad/Ugrad) is '''not''' the same as a CS MySQL-related account, ''even if the usernames are the same.'' Our Linux accounts and our MySQL accounts are two separate types of accounts.

* '''''You cannot ssh into dbase.cs.jhu.edu.''''' The only way you can connect to dbase.cs.jhu.edu is remotely, via a ''MySQL client''.

* If you '''already have a CS ''login'' (ssh) account''' for any of our [[:Category:Linux Clients|CS Department Linux clients]], you can log into one of those Linux systems and use its text-based MySQL client by running <kbd>mysql -h dbase.cs.jhu.edu -u <var>account</var> -p <var>database</var></kbd> , where "<var>account</var>" is your dbase.cs.jhu.edu account name and "<var>database</var>" is the name of your database. You will be prompted to enter your password.

* If you '''do not have a CS ''login'' (ssh) account ''' ''(you '''do not''' need one to access our MySQL service on dbase.cs.jhu.edu''), you can access dbase.cs.jhu.edu with any MySQL client, either text-based or GUI, and, as mentioned before, '''''from any computer on the JHU network, [[Wireless_Networking | JHU's wireless network]] (but not JHGuestnet), or [[VPN_-_JHU | VPN]].''''' Just use "dbase.cs.jhu.edu" as the hostname. If asked for a network port, use "3306". MySQL clients are available for Linux, Mac, and Windows systems.

* Those selected as being the MySQL admin for the specific course must provide us at least one business day to set up a new MySQL admin password for you. At that time, we'll provide you instructions on how to admin the MySQL accounts for the course.
[[Category:MySQL]]

Disk Quotas

2026-09-30T18:44:43Z

Steve410: /* If You Need a Larger Quota on the CS Ugrad Net */

'''CS ''UGRAD'' Net Users:''' Due to the number of students using the Ugrad Linux systems, on the '''''CS Ugrad Net''''', the Ugrad accounts ''are subject to '''disk quotas''''', which are limits on the total amount of data you are permitted to store in your home directory (or, in some cases, other directories). If you exceed a quota, you will be unable to create new files or add to existing files until you reduce the total amount of disk space you're using to go below your quota.

'''CS ''GRAD'' Net Users:''' The '''''CS Grad/Research Net''''' does not currently have disk quotas enabled. But, we ask that users on the CS Grad/Research Net be mindful that you are ''sharing disk space with much of CS''. If you need to store large amounts of data on the CS Grad Net, please see: [[Storing Large Amounts Of Data On Our Systems]]

== How Quotas Work on the ''CS Ugrad Net'' ==

Every account that is subject to a quota has limit on the total amount of disk space used by that account's files. For most of our CS Ugrad accounts, that limit is '''15 GiB'''. Once you hit that limit, all attempts to allocate more space (creating new files, making existing files larger, etc.) will fail.

''If you cannot allocate more space (because you've hit your quota limit), '''you might not be able to log in via the GUI on our Ugrad computer lab Linux systems'''. If that happens, you will have to SSH in remotely and reduce your disk usage below your quota.''

==='''''{{red|IMPORTANT NOTE:}} If You Are Using A ''Cloud Drive'' ('''Dropbox''', '''Google Drive''', etc.)===

:If you have your CS Ugrad Linux account linked to a cloud drive such as '''Dropbox''' or '''Google Drive''', please note that those services may download local copies of your cloud files into your Ugrad account. This is an extremely quick way to go over your CS Ugrad disk quota. We recommend you not link cloud drives with your CS Linux account (unless your cloud drive is very small and well within your CS Ugrad disk quota.) We cannot accomodate users' cloud data within our provided home directory disk resources.

== How to Check Your Quota on the ''CS Ugrad Net'' ==

Log in to one of the [[Linux Clients on the CS Undergrad Net]] and run the following command from the command line:

quota

If it doesn't print anything, you are not subject to any quotas. If it does print something, the output will look like this:

''account'': 1.6GiB used out of 15.0GiB quota

This should be fairly self-explanatory. The person (with account name "''account''") has files totaling 1.6 gigabytes of data. The account's usage limit is 15 gigabytes.

== How to Get Yourself Under Quota on the ''CS Ugrad Net''==

If you're over quota, the only way to get back under is to delete or shrink files until your total disk usage is reduced below your limit.

You can use the <code>du</code> command line program (short for "d"isk "u"sage) to see how much space individual files or directories are using. One of the simplest ways to invoke it is to run the following command from your home directory:

du -h | sort -h

The above command will show you every directory in your home directory (and every subdirectory of them and every subdirectory of those and so on) and how much space it and all of its contents occupies, with the largest directories shown last. The directories containing the most data are probably the best candidates to start cleaning out.

Another useful command is the following:

du -sh * .??* | sort -h

This version of running the du command lists all directories ''and all files'' in the current directory and their sizes. (The ''previous'' version of running the du command shows all directories, not just the ones directly in the current directory, ''and'' it doesn't list files directly; they simply get added to the size tally for the directory they're in.)

:'''NOTE:''' With either of the two above commands, it might be helpful to pipe them to ''less'' or ''more'', or something similar, should your output be long enough to scroll by. For example...

:<pre>du -h | sort -h | less</pre>

Another use of du can provide some additional detail of what files are taking up the most space:

du -ha |sort -h |tail

=== If You Have .nfs Files ===

If, from the above list of commands, you run:

du -sh * .??* | sort -h

and you notice a file with a name starting with "<code>.nfs</code>" followed by a long string of numbers, you will want to remove it, as it can be a very large (and unwanted) file. And it's not a file you can use the <code>rm</code> command with (unlike other with other files.)

The .nfs file is created when some other file ''is deleted'' while a running program ''is still using'' that file. Our systems simply renames that other file (that you deleted) to <code>.nfs</code> (followed by a long string of numbers) while the program is still running. As soon as the program exits, the <code>.nfs</code> file will be removed. But, if the .nfs file remains in your directory, as mentioned, you cannot simply remove it with a <code>rm</code> command, as you would do with regular files. The .nfs file remains because there is some process/program open that is keeping the .nfs file in place. If you tried to directly remove the .nfs file that some process has open, there would be a replacement .nfs file created. So, you need to stop the program that is running that is keeping the .nfs file open.

If you need to figure out what program is using the file, you can use the <code>lsof</code> program, like this:

lsof .nfs''000000003114807500000002''

(Obviously, use the actual name of the file in your directory.) Its output will look something like this:

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
pv 9671 example 1w REG 0,45 167772160 823427189 .nfs000000003114807500000002

The most useful information is at the beginning, giving the name and process ID of the running program.

''This will only work on the system running the program.'' If, for example, you started a program on our <code>ugradx</code> system, you would only see useful information from <code>lsof</code> if you also ran it on <code>ugradx</code>. If you ran it on, say, <code>ugradz</code>, it would still see the <code>.nfs</code> file (because all the ugrad systems see the same home directory folders), but it wouldn't be able to find what program was using it.

=== If You Can't Find any Large Files ===

Sometimes the <code>quota</code> program will say that you're using a lot of disk space, but the <code>du</code> command doesn't show anything large.

One common cause for this is because of a quirk in Unix filesystem behavior. If a you delete a file while it's in use by a running program, the file will disappear from the directory, ''but it will still exist, invisibly using disk space'' until the running program exits. Even worse, if the program writes data to this deleted file, the extra data gets counted against your quota, even though you can't see the file. (Usually when you delete a file that's in use you'll get a .nfs file, [[#If You Have .nfs Files|as described above]], but sometimes the file will just disappear entirely.)

You can use the <code>lsof</code> program to find files that have deen deleted but are still in use, like this:

lsof +aL1 /home

If you have any files in this state, it'll print something like this:

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME
pv 16081 example 1w REG 0,45 159907840 0 823427190 /home/example/inuse (barley.cs.jhu.edu:/home)

That will show the name of the program and the location where the file used to be before it was deleted. If you don't have any other way to stop the program, you can usually terminate it with the <code>kill</code> command, like this:

kill ''16081''

For the number, use the process ID (PID) from <code>lsof</code>'s output.

''This will only work if you run <code>lsof</code> on the same system where the other program is running.'' You might need to log into several systems to check things if you've used more than one for your recent work.

=== If You Still Can't Reduce Your Disk Usage ===

If the system insists that you're over quota but you can't figure out why, you can always email us at [mailto:support@cs.jhu.edu support@cs.jhu.edu] for assistance.

== A Note on File Size and Disk Usage ==

On our systems, files are compressed before they're stored on disk. Consequently, the disk space used by a file (what you see if you run <kbd>du -sh <var>file</var></kbd>) is likely to be smaller than the amount of data stored in the file (which is what you see if you run <kbd>ls -lh <var>file</var></kbd>). Since our quotas are based on the actual amount of disk space used, the sizes shown by <code>du</code> are most relevant here. If you rely on just the sizes shown by <code>ls</code>, you might be misled about how much your quota is being affected by particular files.

== If You Need a Larger Quota on the ''CS Ugrad Net''==

If your class projects or research require more disk space than your quota will allow, please contact [mailto:support@cs.jhu.edu support@cs.jhu.edu] and detail the reasons your current quota is insufficient. (Note: Please ''do not'' request a larger disk quota to accommodate ''cloud drives'' such as '''Dropbox''' and '''Google Drive'''.) Please include the following information when requesting more disk space:

* Your CS username
* CS student status (ugrad? grad? concurrent?)
* Your JHED ID
* How much additional space you require.
* Name ''and'' section of class you're taking that's requiring the extra space.
* Name of the professor teaching the class.
* How long you need the increased quota. (After that, your quota would be reduced to its normal level, and you will need to be below that level to write files to your directory.)

''Quota increases are not guaranteed. Allow '''at least''' one full business day for your quota increase request to be processed.''

[[Category:Accounts]]
[[Category:Linux Clients]]

Disk Quotas

2026-09-30T18:44:25Z

Steve410: /* If You Need a Larger Quota on the CS Ugrad Net */

'''CS ''UGRAD'' Net Users:''' Due to the number of students using the Ugrad Linux systems, on the '''''CS Ugrad Net''''', the Ugrad accounts ''are subject to '''disk quotas''''', which are limits on the total amount of data you are permitted to store in your home directory (or, in some cases, other directories). If you exceed a quota, you will be unable to create new files or add to existing files until you reduce the total amount of disk space you're using to go below your quota.

'''CS ''GRAD'' Net Users:''' The '''''CS Grad/Research Net''''' does not currently have disk quotas enabled. But, we ask that users on the CS Grad/Research Net be mindful that you are ''sharing disk space with much of CS''. If you need to store large amounts of data on the CS Grad Net, please see: [[Storing Large Amounts Of Data On Our Systems]]

== How Quotas Work on the ''CS Ugrad Net'' ==

Every account that is subject to a quota has limit on the total amount of disk space used by that account's files. For most of our CS Ugrad accounts, that limit is '''15 GiB'''. Once you hit that limit, all attempts to allocate more space (creating new files, making existing files larger, etc.) will fail.

''If you cannot allocate more space (because you've hit your quota limit), '''you might not be able to log in via the GUI on our Ugrad computer lab Linux systems'''. If that happens, you will have to SSH in remotely and reduce your disk usage below your quota.''

==='''''{{red|IMPORTANT NOTE:}} If You Are Using A ''Cloud Drive'' ('''Dropbox''', '''Google Drive''', etc.)===

:If you have your CS Ugrad Linux account linked to a cloud drive such as '''Dropbox''' or '''Google Drive''', please note that those services may download local copies of your cloud files into your Ugrad account. This is an extremely quick way to go over your CS Ugrad disk quota. We recommend you not link cloud drives with your CS Linux account (unless your cloud drive is very small and well within your CS Ugrad disk quota.) We cannot accomodate users' cloud data within our provided home directory disk resources.

== How to Check Your Quota on the ''CS Ugrad Net'' ==

Log in to one of the [[Linux Clients on the CS Undergrad Net]] and run the following command from the command line:

quota

If it doesn't print anything, you are not subject to any quotas. If it does print something, the output will look like this:

''account'': 1.6GiB used out of 15.0GiB quota

This should be fairly self-explanatory. The person (with account name "''account''") has files totaling 1.6 gigabytes of data. The account's usage limit is 15 gigabytes.

== How to Get Yourself Under Quota on the ''CS Ugrad Net''==

If you're over quota, the only way to get back under is to delete or shrink files until your total disk usage is reduced below your limit.

You can use the <code>du</code> command line program (short for "d"isk "u"sage) to see how much space individual files or directories are using. One of the simplest ways to invoke it is to run the following command from your home directory:

du -h | sort -h

The above command will show you every directory in your home directory (and every subdirectory of them and every subdirectory of those and so on) and how much space it and all of its contents occupies, with the largest directories shown last. The directories containing the most data are probably the best candidates to start cleaning out.

Another useful command is the following:

du -sh * .??* | sort -h

This version of running the du command lists all directories ''and all files'' in the current directory and their sizes. (The ''previous'' version of running the du command shows all directories, not just the ones directly in the current directory, ''and'' it doesn't list files directly; they simply get added to the size tally for the directory they're in.)

:'''NOTE:''' With either of the two above commands, it might be helpful to pipe them to ''less'' or ''more'', or something similar, should your output be long enough to scroll by. For example...

:<pre>du -h | sort -h | less</pre>

Another use of du can provide some additional detail of what files are taking up the most space:

du -ha |sort -h |tail

=== If You Have .nfs Files ===

If, from the above list of commands, you run:

du -sh * .??* | sort -h

and you notice a file with a name starting with "<code>.nfs</code>" followed by a long string of numbers, you will want to remove it, as it can be a very large (and unwanted) file. And it's not a file you can use the <code>rm</code> command with (unlike other with other files.)

The .nfs file is created when some other file ''is deleted'' while a running program ''is still using'' that file. Our systems simply renames that other file (that you deleted) to <code>.nfs</code> (followed by a long string of numbers) while the program is still running. As soon as the program exits, the <code>.nfs</code> file will be removed. But, if the .nfs file remains in your directory, as mentioned, you cannot simply remove it with a <code>rm</code> command, as you would do with regular files. The .nfs file remains because there is some process/program open that is keeping the .nfs file in place. If you tried to directly remove the .nfs file that some process has open, there would be a replacement .nfs file created. So, you need to stop the program that is running that is keeping the .nfs file open.

If you need to figure out what program is using the file, you can use the <code>lsof</code> program, like this:

lsof .nfs''000000003114807500000002''

(Obviously, use the actual name of the file in your directory.) Its output will look something like this:

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
pv 9671 example 1w REG 0,45 167772160 823427189 .nfs000000003114807500000002

The most useful information is at the beginning, giving the name and process ID of the running program.

''This will only work on the system running the program.'' If, for example, you started a program on our <code>ugradx</code> system, you would only see useful information from <code>lsof</code> if you also ran it on <code>ugradx</code>. If you ran it on, say, <code>ugradz</code>, it would still see the <code>.nfs</code> file (because all the ugrad systems see the same home directory folders), but it wouldn't be able to find what program was using it.

=== If You Can't Find any Large Files ===

Sometimes the <code>quota</code> program will say that you're using a lot of disk space, but the <code>du</code> command doesn't show anything large.

One common cause for this is because of a quirk in Unix filesystem behavior. If a you delete a file while it's in use by a running program, the file will disappear from the directory, ''but it will still exist, invisibly using disk space'' until the running program exits. Even worse, if the program writes data to this deleted file, the extra data gets counted against your quota, even though you can't see the file. (Usually when you delete a file that's in use you'll get a .nfs file, [[#If You Have .nfs Files|as described above]], but sometimes the file will just disappear entirely.)

You can use the <code>lsof</code> program to find files that have deen deleted but are still in use, like this:

lsof +aL1 /home

If you have any files in this state, it'll print something like this:

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME
pv 16081 example 1w REG 0,45 159907840 0 823427190 /home/example/inuse (barley.cs.jhu.edu:/home)

That will show the name of the program and the location where the file used to be before it was deleted. If you don't have any other way to stop the program, you can usually terminate it with the <code>kill</code> command, like this:

kill ''16081''

For the number, use the process ID (PID) from <code>lsof</code>'s output.

''This will only work if you run <code>lsof</code> on the same system where the other program is running.'' You might need to log into several systems to check things if you've used more than one for your recent work.

=== If You Still Can't Reduce Your Disk Usage ===

If the system insists that you're over quota but you can't figure out why, you can always email us at [mailto:support@cs.jhu.edu support@cs.jhu.edu] for assistance.

== A Note on File Size and Disk Usage ==

On our systems, files are compressed before they're stored on disk. Consequently, the disk space used by a file (what you see if you run <kbd>du -sh <var>file</var></kbd>) is likely to be smaller than the amount of data stored in the file (which is what you see if you run <kbd>ls -lh <var>file</var></kbd>). Since our quotas are based on the actual amount of disk space used, the sizes shown by <code>du</code> are most relevant here. If you rely on just the sizes shown by <code>ls</code>, you might be misled about how much your quota is being affected by particular files.

== If You Need a Larger Quota on the ''CS Ugrad Net''==

If your class projects or research require more disk space than your quota will allow, please contact [mailto:support@cs.jhu.edu support@cs.jhu.edu] and detail the reasons your current quota is insufficient. (Note: Please ''do not'' request a larger disk quota to accommodate ''cloud drives'' such as '''Dropbox''' and '''Google Drive'''.) Please include the following information when requesting more disk space:

* Your CS username
* CS student status (ugrad? grad? concurrent?)
* Your JHED ID
* How much additional space you require.
* Name ''and'' section of class you're taking that's requiring the extra space.
* Name of the professor teaching the class.
* How long you need the increased quota. (After that, your quota will be reduced to its normal level, and you will need to be below that level to write files to your directory.)

''Quota increases are not guaranteed. Allow '''at least''' one full business day for your quota increase request to be processed.''

[[Category:Accounts]]
[[Category:Linux Clients]]

Using VNC To Access CS Linux Computers

2026-09-29T20:51:46Z

Steve410: /* STEP 3: Starting the VNC client on your Local system */

VNC ([https://en.wikipedia.org/wiki/Virtual_Network_Computing Virtual Network Computing]) is supported as a method for remotely accessing our [[:Category:Linux Clients|Linux Clients]]. Because VNC does not, by default, provide a securely encrypted network connection, you will need to tunnel your connections through SSH. Instructions for doing so are below.

Please keep in mind that our Linux clients are for everyone's use and graphical programs can use many system resources. Do not leave VNC sessions running unless you're actively using them. We reserve the right to terminate idle sessions in order to free up resources for others' use.

'''In the examples used below, we want to view the desktop of the remote system, ''ugradx'' by connecting as user ''joeuser''.'''

== ''STEP 1'': Starting the VNC Service on the Remote Computer ==

To start a VNC server on the remote Linux system from your own Windows, Mac,or Linux system:

*Open Windows Powershell, Mac Terminal or Linux shell

* ssh ''joeuser''@''ugradx''.cs.jhu.edu

* run “vncserver”

::'''NOTE:''' If this is the ''first time you're running vncserver'', the first thing it will do is prompt you to enter a new password that will be used in later steps when accessing from a vnc client. You will also be asked if this new password is for view-only. You may say "n" for "no". (Note that the password is needed because of the way VNC works.

:: Anyone who can log in to the system can connect to ''any'' VNC session running on the system, regardless of who started that session. The password ensures that only you can use your sessions.)

::At a later time, should you need to reset your vnc password (e.g., you forgot the password), ssh back into the system and run <code>vncpasswd</code> (Currently, vncpasswd will only allow up to 8 characters, unlike regular login passwords.)

* Look for the line indicating a new desktop... '''New ''ugradx'':1 (''joeuser'') desktop is ugradx:1''' (or something similar.)

* Notice what the number after the colon is. e.g. '''''ugradx'':1''' We'll call the number following the ''':''' the ''display number''. You might see a different number. That's ok. You'll need the display number you get for next step.

* '''''Add''''' the display number you noticed in the prior step to value of '''5900''' to create a new port number for vncserver to use in later steps. For example, using ''':1''' from the previous step, add that value of '''''1''''' to '''5900''' to get the new value of '''5901'''. This is a port number, and we'll need this during the upcoming "tunneling-through-ssh" section.

== ''STEP 2:'' Tunneling Your VNC Session through SSH ==

You must tunnel your VNC session through SSH for remote access to our our CS Linux computers so that your session is secured. To connect to the remote linux system, you will have to set up an SSH TCP tunnel to the port the server is listening on. That port number is '''5900''' '''''plus the X display number,''''' so it will most often be port '''5901''', as in our earlier example.

The following steps to set up tunneling should work with Windows, Mac, and Linux clients.

On your '''local''' system:

* Open a new terminal ('''but also leaving the ''other'' terminal you ran earlier to start "vncserver" still open and running'''.)

* From the new terminal, run '''ssh -L 5901:localhost:5901 ''joeuser''@''ugradx''.cs.jhu.edu''' and log in as you normally would to ''ugradx''. (Remember, use the port number you came up with in the earlier steps.)

The tunnel is now set. Onto starting the vnc-type client on your local system...

== ''STEP 3:'' Starting the VNC client on your Local system==

 
'''''IMPORTANT:'' Leave those ''two'' ssh sessions from earlier running.'''

===Starting a Windows or Linux VNC Client===

* Open your Windows or Linux VNC client on your local system. (If you don't have a VNC client, try [http://www.tigervnc.com/ TigerVNC] and the following steps will assume you're using TigerVNC.)

* Connect to "localhost:1", where ":1" is the actual display number used by your VNC server. You might've used a different display number in earlier steps. And for this step, you do not need the ''590x'' part when inputting the port number in this step..

* Type in the password you gave when setting up the VNC server for ugradx

* You are now connected, with the remote ugradx desktop now displayed securely on your local desktop.

===Starting a Mac VNC Client===
* Point your mouse on the Mac desktop (not on a mac app or window), and click to make sure the desktop is activated.

* Press '''⌘ k'''

* A ''Connect to Server'' window pops up.

* In the empty field, type in the following: '''vnc://localhost:5901''' (or whichever ''port number'' you calculated from an earlier step.)

* A ''Screen Sharing'' window will open.

* Type in the password you gave when setting up the VNC server for ugradx

* You are now connected, with the remote ugradx desktop now displayed securely on your local desktop.

== ''STEP 4:'' {{red|''IMPORTANT:''}} When you are finished with your VNC connection...==

* Choose either ssh terminal window for which you have a connection to ''ugradx''

* Run: <code>vncserver -kill :1</code> (for the :number, use the display number from the earlier steps. {{red|And make sure you have a space between the ''-kill'' and the '':port #''}})

* Close your VNC client on your local system.

* Close your SSH terminals.

[[Category:Linux Clients]]
[[Category:Software]]
[[Category:Networking]]
[[Category:SSH]]

Using VNC To Access CS Linux Computers

2026-09-29T20:51:27Z

Steve410: /* STEP 3: Starting the VNC client on your Local system */

VNC ([https://en.wikipedia.org/wiki/Virtual_Network_Computing Virtual Network Computing]) is supported as a method for remotely accessing our [[:Category:Linux Clients|Linux Clients]]. Because VNC does not, by default, provide a securely encrypted network connection, you will need to tunnel your connections through SSH. Instructions for doing so are below.

Please keep in mind that our Linux clients are for everyone's use and graphical programs can use many system resources. Do not leave VNC sessions running unless you're actively using them. We reserve the right to terminate idle sessions in order to free up resources for others' use.

'''In the examples used below, we want to view the desktop of the remote system, ''ugradx'' by connecting as user ''joeuser''.'''

== ''STEP 1'': Starting the VNC Service on the Remote Computer ==

To start a VNC server on the remote Linux system from your own Windows, Mac,or Linux system:

*Open Windows Powershell, Mac Terminal or Linux shell

* ssh ''joeuser''@''ugradx''.cs.jhu.edu

* run “vncserver”

::'''NOTE:''' If this is the ''first time you're running vncserver'', the first thing it will do is prompt you to enter a new password that will be used in later steps when accessing from a vnc client. You will also be asked if this new password is for view-only. You may say "n" for "no". (Note that the password is needed because of the way VNC works.

:: Anyone who can log in to the system can connect to ''any'' VNC session running on the system, regardless of who started that session. The password ensures that only you can use your sessions.)

::At a later time, should you need to reset your vnc password (e.g., you forgot the password), ssh back into the system and run <code>vncpasswd</code> (Currently, vncpasswd will only allow up to 8 characters, unlike regular login passwords.)

* Look for the line indicating a new desktop... '''New ''ugradx'':1 (''joeuser'') desktop is ugradx:1''' (or something similar.)

* Notice what the number after the colon is. e.g. '''''ugradx'':1''' We'll call the number following the ''':''' the ''display number''. You might see a different number. That's ok. You'll need the display number you get for next step.

* '''''Add''''' the display number you noticed in the prior step to value of '''5900''' to create a new port number for vncserver to use in later steps. For example, using ''':1''' from the previous step, add that value of '''''1''''' to '''5900''' to get the new value of '''5901'''. This is a port number, and we'll need this during the upcoming "tunneling-through-ssh" section.

== ''STEP 2:'' Tunneling Your VNC Session through SSH ==

You must tunnel your VNC session through SSH for remote access to our our CS Linux computers so that your session is secured. To connect to the remote linux system, you will have to set up an SSH TCP tunnel to the port the server is listening on. That port number is '''5900''' '''''plus the X display number,''''' so it will most often be port '''5901''', as in our earlier example.

The following steps to set up tunneling should work with Windows, Mac, and Linux clients.

On your '''local''' system:

* Open a new terminal ('''but also leaving the ''other'' terminal you ran earlier to start "vncserver" still open and running'''.)

* From the new terminal, run '''ssh -L 5901:localhost:5901 ''joeuser''@''ugradx''.cs.jhu.edu''' and log in as you normally would to ''ugradx''. (Remember, use the port number you came up with in the earlier steps.)

The tunnel is now set. Onto starting the vnc-type client on your local system...

== ''STEP 3:'' Starting the VNC client on your Local system==

 
'''''IMPORTANT:'' Leave those ''two'' ssh sessions from earlier running.'''

:===Starting a Windows or Linux VNC Client===

* Open your Windows or Linux VNC client on your local system. (If you don't have a VNC client, try [http://www.tigervnc.com/ TigerVNC] and the following steps will assume you're using TigerVNC.)

* Connect to "localhost:1", where ":1" is the actual display number used by your VNC server. You might've used a different display number in earlier steps. And for this step, you do not need the ''590x'' part when inputting the port number in this step..

* Type in the password you gave when setting up the VNC server for ugradx

* You are now connected, with the remote ugradx desktop now displayed securely on your local desktop.

===Starting a Mac VNC Client===
* Point your mouse on the Mac desktop (not on a mac app or window), and click to make sure the desktop is activated.

* Press '''⌘ k'''

* A ''Connect to Server'' window pops up.

* In the empty field, type in the following: '''vnc://localhost:5901''' (or whichever ''port number'' you calculated from an earlier step.)

* A ''Screen Sharing'' window will open.

* Type in the password you gave when setting up the VNC server for ugradx

* You are now connected, with the remote ugradx desktop now displayed securely on your local desktop.

== ''STEP 4:'' {{red|''IMPORTANT:''}} When you are finished with your VNC connection...==

* Choose either ssh terminal window for which you have a connection to ''ugradx''

* Run: <code>vncserver -kill :1</code> (for the :number, use the display number from the earlier steps. {{red|And make sure you have a space between the ''-kill'' and the '':port #''}})

* Close your VNC client on your local system.

* Close your SSH terminals.

[[Category:Linux Clients]]
[[Category:Software]]
[[Category:Networking]]
[[Category:SSH]]

Using VNC To Access CS Linux Computers

2026-09-29T19:58:52Z

Steve410: /* STEP 4: IMPORTANT: When you are finished with your VNC connection... */

Using VNC To Access CS Linux Computers

2026-09-29T19:58:11Z

Steve410: /* STEP 3: Starting the VNC client on your Local system */

VNC ([https://en.wikipedia.org/wiki/Virtual_Network_Computing Virtual Network Computing]) is supported as a method for remotely accessing our [[:Category:Linux Clients|Linux Clients]]. Because VNC does not, by default, provide a securely encrypted network connection, you will need to tunnel your connections through SSH. Instructions for doing so are below.

Please keep in mind that our Linux clients are for everyone's use and graphical programs can use many system resources. Do not leave VNC sessions running unless you're actively using them. We reserve the right to terminate idle sessions in order to free up resources for others' use.

'''In the examples used below, we want to view the desktop of the remote system, ''ugradx'' by connecting as user ''joeuser''.'''

== ''STEP 1'': Starting the VNC Service on the Remote Computer ==

To start a VNC server on the remote Linux system from your own Windows, Mac,or Linux system:

*Open Windows Powershell, Mac Terminal or Linux shell

* ssh ''joeuser''@''ugradx''.cs.jhu.edu

* run “vncserver”

::'''NOTE:''' If this is the ''first time you're running vncserver'', the first thing it will do is prompt you to enter a new password that will be used in later steps when accessing from a vnc client. You will also be asked if this new password is for view-only. You may say "n" for "no". (Note that the password is needed because of the way VNC works.

:: Anyone who can log in to the system can connect to ''any'' VNC session running on the system, regardless of who started that session. The password ensures that only you can use your sessions.)

::At a later time, should you need to reset your vnc password (e.g., you forgot the password), ssh back into the system and run <code>vncpasswd</code> (Currently, vncpasswd will only allow up to 8 characters, unlike regular login passwords.)

* Look for the line indicating a new desktop... '''New ''ugradx'':1 (''joeuser'') desktop is ugradx:1''' (or something similar.)

* Notice what the number after the colon is. e.g. '''''ugradx'':1''' We'll call the number following the ''':''' the ''display number''. You might see a different number. That's ok. You'll need the display number you get for next step.

* '''''Add''''' the display number you noticed in the prior step to value of '''5900''' to create a new port number for vncserver to use in later steps. For example, using ''':1''' from the previous step, add that value of '''''1''''' to '''5900''' to get the new value of '''5901'''. This is a port number, and we'll need this during the upcoming "tunneling-through-ssh" section.

== ''STEP 2:'' Tunneling Your VNC Session through SSH ==

You must tunnel your VNC session through SSH for remote access to our our CS Linux computers so that your session is secured. To connect to the remote linux system, you will have to set up an SSH TCP tunnel to the port the server is listening on. That port number is '''5900''' '''''plus the X display number,''''' so it will most often be port '''5901''', as in our earlier example.

The following steps to set up tunneling should work with Windows, Mac, and Linux clients.

On your '''local''' system:

* Open a new terminal ('''but also leaving the ''other'' terminal you ran earlier to start "vncserver" still open and running'''.)

* From the new terminal, run '''ssh -L 5901:localhost:5901 ''joeuser''@''ugradx''.cs.jhu.edu''' and log in as you normally would to ''ugradx''. (Remember, use the port number you came up with in the earlier steps.)

The tunnel is now set. Onto starting the vnc-type client on your local system...

== ''STEP 3:'' Starting the VNC client on your Local system==

 
'''''IMPORTANT:'' Leave those ''two'' ssh sessions from earlier running.'''

===Starting a Windows or Linux VNC Client===

* Open your Windows or Linux VNC client on your local system. (If you don't have a VNC client, try [http://www.tigervnc.com/ TigerVNC] and the following steps will assume you're using TigerVNC.)

* Connect to "localhost:1", where ":1" is the actual display number used by your VNC server. You might've used a different display number in earlier steps. And for this step, you do not need the ''590x'' part when inputting the port number in this step..

* Type in the password you gave when setting up the VNC server for ugradx

* You are now connected, with the remote ugradx desktop now displayed securely on your local desktop.

===Starting a Mac VNC Client===
* Point your mouse on the Mac desktop (not on a mac app or window), and click to make sure the desktop is activated.

* Press '''⌘ k'''

* A ''Connect to Server'' window pops up.

* In the empty field, type in the following: '''vnc://localhost:5901''' (or whichever ''port number'' you calculated from an earlier step.)

* A ''Screen Sharing'' window will open.

* Type in the password you gave when setting up the VNC server for ugradx

* You are now connected, with the remote ugradx desktop now displayed securely on your local desktop.

== STEP 4: ''IMPORTANT:'' When you are finished with your VNC connection...==

* Choose either ssh terminal window for which you have a connection to ''ugradx''

* Run: <code>vncserver -kill :1</code> (for the :number, use the display number from the earlier steps. {{red|And make sure you have a space between the ''-kill'' and the '':port #''}})

* Close your VNC client on your local system.

* Close your SSH terminals.

[[Category:Linux Clients]]
[[Category:Software]]
[[Category:Networking]]
[[Category:SSH]]

Using VNC To Access CS Linux Computers

2026-09-29T19:58:03Z

Steve410: /* STEP 2: Tunneling Your VNC Session through SSH */

VNC ([https://en.wikipedia.org/wiki/Virtual_Network_Computing Virtual Network Computing]) is supported as a method for remotely accessing our [[:Category:Linux Clients|Linux Clients]]. Because VNC does not, by default, provide a securely encrypted network connection, you will need to tunnel your connections through SSH. Instructions for doing so are below.

Please keep in mind that our Linux clients are for everyone's use and graphical programs can use many system resources. Do not leave VNC sessions running unless you're actively using them. We reserve the right to terminate idle sessions in order to free up resources for others' use.

'''In the examples used below, we want to view the desktop of the remote system, ''ugradx'' by connecting as user ''joeuser''.'''

== ''STEP 1'': Starting the VNC Service on the Remote Computer ==

To start a VNC server on the remote Linux system from your own Windows, Mac,or Linux system:

*Open Windows Powershell, Mac Terminal or Linux shell

* ssh ''joeuser''@''ugradx''.cs.jhu.edu

* run “vncserver”

::'''NOTE:''' If this is the ''first time you're running vncserver'', the first thing it will do is prompt you to enter a new password that will be used in later steps when accessing from a vnc client. You will also be asked if this new password is for view-only. You may say "n" for "no". (Note that the password is needed because of the way VNC works.

:: Anyone who can log in to the system can connect to ''any'' VNC session running on the system, regardless of who started that session. The password ensures that only you can use your sessions.)

::At a later time, should you need to reset your vnc password (e.g., you forgot the password), ssh back into the system and run <code>vncpasswd</code> (Currently, vncpasswd will only allow up to 8 characters, unlike regular login passwords.)

* Look for the line indicating a new desktop... '''New ''ugradx'':1 (''joeuser'') desktop is ugradx:1''' (or something similar.)

* Notice what the number after the colon is. e.g. '''''ugradx'':1''' We'll call the number following the ''':''' the ''display number''. You might see a different number. That's ok. You'll need the display number you get for next step.

* '''''Add''''' the display number you noticed in the prior step to value of '''5900''' to create a new port number for vncserver to use in later steps. For example, using ''':1''' from the previous step, add that value of '''''1''''' to '''5900''' to get the new value of '''5901'''. This is a port number, and we'll need this during the upcoming "tunneling-through-ssh" section.

== ''STEP 2:'' Tunneling Your VNC Session through SSH ==

You must tunnel your VNC session through SSH for remote access to our our CS Linux computers so that your session is secured. To connect to the remote linux system, you will have to set up an SSH TCP tunnel to the port the server is listening on. That port number is '''5900''' '''''plus the X display number,''''' so it will most often be port '''5901''', as in our earlier example.

The following steps to set up tunneling should work with Windows, Mac, and Linux clients.

On your '''local''' system:

* Open a new terminal ('''but also leaving the ''other'' terminal you ran earlier to start "vncserver" still open and running'''.)

* From the new terminal, run '''ssh -L 5901:localhost:5901 ''joeuser''@''ugradx''.cs.jhu.edu''' and log in as you normally would to ''ugradx''. (Remember, use the port number you came up with in the earlier steps.)

The tunnel is now set. Onto starting the vnc-type client on your local system...

== STEP 3: Starting the VNC client on your Local system==

 
'''''IMPORTANT:'' Leave those ''two'' ssh sessions from earlier running.'''

===Starting a Windows or Linux VNC Client===

* Open your Windows or Linux VNC client on your local system. (If you don't have a VNC client, try [http://www.tigervnc.com/ TigerVNC] and the following steps will assume you're using TigerVNC.)

* Connect to "localhost:1", where ":1" is the actual display number used by your VNC server. You might've used a different display number in earlier steps. And for this step, you do not need the ''590x'' part when inputting the port number in this step..

* Type in the password you gave when setting up the VNC server for ugradx

* You are now connected, with the remote ugradx desktop now displayed securely on your local desktop.

===Starting a Mac VNC Client===
* Point your mouse on the Mac desktop (not on a mac app or window), and click to make sure the desktop is activated.

* Press '''⌘ k'''

* A ''Connect to Server'' window pops up.

* In the empty field, type in the following: '''vnc://localhost:5901''' (or whichever ''port number'' you calculated from an earlier step.)

* A ''Screen Sharing'' window will open.

* Type in the password you gave when setting up the VNC server for ugradx

* You are now connected, with the remote ugradx desktop now displayed securely on your local desktop.

== STEP 4: ''IMPORTANT:'' When you are finished with your VNC connection...==

* Choose either ssh terminal window for which you have a connection to ''ugradx''

* Run: <code>vncserver -kill :1</code> (for the :number, use the display number from the earlier steps. {{red|And make sure you have a space between the ''-kill'' and the '':port #''}})

* Close your VNC client on your local system.

* Close your SSH terminals.

[[Category:Linux Clients]]
[[Category:Software]]
[[Category:Networking]]
[[Category:SSH]]

Using VNC To Access CS Linux Computers

2026-09-29T19:57:50Z

Steve410: /* STEP 1: Starting the VNC Service on the Remote Computer */

VNC ([https://en.wikipedia.org/wiki/Virtual_Network_Computing Virtual Network Computing]) is supported as a method for remotely accessing our [[:Category:Linux Clients|Linux Clients]]. Because VNC does not, by default, provide a securely encrypted network connection, you will need to tunnel your connections through SSH. Instructions for doing so are below.

Please keep in mind that our Linux clients are for everyone's use and graphical programs can use many system resources. Do not leave VNC sessions running unless you're actively using them. We reserve the right to terminate idle sessions in order to free up resources for others' use.

'''In the examples used below, we want to view the desktop of the remote system, ''ugradx'' by connecting as user ''joeuser''.'''

== ''STEP 1'': Starting the VNC Service on the Remote Computer ==

To start a VNC server on the remote Linux system from your own Windows, Mac,or Linux system:

*Open Windows Powershell, Mac Terminal or Linux shell

* ssh ''joeuser''@''ugradx''.cs.jhu.edu

* run “vncserver”

::'''NOTE:''' If this is the ''first time you're running vncserver'', the first thing it will do is prompt you to enter a new password that will be used in later steps when accessing from a vnc client. You will also be asked if this new password is for view-only. You may say "n" for "no". (Note that the password is needed because of the way VNC works.

:: Anyone who can log in to the system can connect to ''any'' VNC session running on the system, regardless of who started that session. The password ensures that only you can use your sessions.)

::At a later time, should you need to reset your vnc password (e.g., you forgot the password), ssh back into the system and run <code>vncpasswd</code> (Currently, vncpasswd will only allow up to 8 characters, unlike regular login passwords.)

* Look for the line indicating a new desktop... '''New ''ugradx'':1 (''joeuser'') desktop is ugradx:1''' (or something similar.)

* Notice what the number after the colon is. e.g. '''''ugradx'':1''' We'll call the number following the ''':''' the ''display number''. You might see a different number. That's ok. You'll need the display number you get for next step.

* '''''Add''''' the display number you noticed in the prior step to value of '''5900''' to create a new port number for vncserver to use in later steps. For example, using ''':1''' from the previous step, add that value of '''''1''''' to '''5900''' to get the new value of '''5901'''. This is a port number, and we'll need this during the upcoming "tunneling-through-ssh" section.

== STEP 2: Tunneling Your VNC Session through SSH ==

You must tunnel your VNC session through SSH for remote access to our our CS Linux computers so that your session is secured. To connect to the remote linux system, you will have to set up an SSH TCP tunnel to the port the server is listening on. That port number is '''5900''' '''''plus the X display number,''''' so it will most often be port '''5901''', as in our earlier example.

The following steps to set up tunneling should work with Windows, Mac, and Linux clients.

On your '''local''' system:

* Open a new terminal ('''but also leaving the ''other'' terminal you ran earlier to start "vncserver" still open and running'''.)

* From the new terminal, run '''ssh -L 5901:localhost:5901 ''joeuser''@''ugradx''.cs.jhu.edu''' and log in as you normally would to ''ugradx''. (Remember, use the port number you came up with in the earlier steps.)

The tunnel is now set. Onto starting the vnc-type client on your local system...

== STEP 3: Starting the VNC client on your Local system==

 
'''''IMPORTANT:'' Leave those ''two'' ssh sessions from earlier running.'''

===Starting a Windows or Linux VNC Client===

* Open your Windows or Linux VNC client on your local system. (If you don't have a VNC client, try [http://www.tigervnc.com/ TigerVNC] and the following steps will assume you're using TigerVNC.)

* Connect to "localhost:1", where ":1" is the actual display number used by your VNC server. You might've used a different display number in earlier steps. And for this step, you do not need the ''590x'' part when inputting the port number in this step..

* Type in the password you gave when setting up the VNC server for ugradx

* You are now connected, with the remote ugradx desktop now displayed securely on your local desktop.

===Starting a Mac VNC Client===
* Point your mouse on the Mac desktop (not on a mac app or window), and click to make sure the desktop is activated.

* Press '''⌘ k'''

* A ''Connect to Server'' window pops up.

* In the empty field, type in the following: '''vnc://localhost:5901''' (or whichever ''port number'' you calculated from an earlier step.)

* A ''Screen Sharing'' window will open.

* Type in the password you gave when setting up the VNC server for ugradx

* You are now connected, with the remote ugradx desktop now displayed securely on your local desktop.

== STEP 4: ''IMPORTANT:'' When you are finished with your VNC connection...==

* Choose either ssh terminal window for which you have a connection to ''ugradx''

* Run: <code>vncserver -kill :1</code> (for the :number, use the display number from the earlier steps. {{red|And make sure you have a space between the ''-kill'' and the '':port #''}})

* Close your VNC client on your local system.

* Close your SSH terminals.

[[Category:Linux Clients]]
[[Category:Software]]
[[Category:Networking]]
[[Category:SSH]]

Using VNC To Access CS Linux Computers

2026-09-29T19:57:35Z

Steve410: /* STEP 1: Starting the VNC Service on the Remote Computer */

VNC ([https://en.wikipedia.org/wiki/Virtual_Network_Computing Virtual Network Computing]) is supported as a method for remotely accessing our [[:Category:Linux Clients|Linux Clients]]. Because VNC does not, by default, provide a securely encrypted network connection, you will need to tunnel your connections through SSH. Instructions for doing so are below.

Please keep in mind that our Linux clients are for everyone's use and graphical programs can use many system resources. Do not leave VNC sessions running unless you're actively using them. We reserve the right to terminate idle sessions in order to free up resources for others' use.

'''In the examples used below, we want to view the desktop of the remote system, ''ugradx'' by connecting as user ''joeuser''.'''

== '''STEP 1''': Starting the VNC Service on the Remote Computer ==

To start a VNC server on the remote Linux system from your own Windows, Mac,or Linux system:

*Open Windows Powershell, Mac Terminal or Linux shell

* ssh ''joeuser''@''ugradx''.cs.jhu.edu

* run “vncserver”

::'''NOTE:''' If this is the ''first time you're running vncserver'', the first thing it will do is prompt you to enter a new password that will be used in later steps when accessing from a vnc client. You will also be asked if this new password is for view-only. You may say "n" for "no". (Note that the password is needed because of the way VNC works.

:: Anyone who can log in to the system can connect to ''any'' VNC session running on the system, regardless of who started that session. The password ensures that only you can use your sessions.)

::At a later time, should you need to reset your vnc password (e.g., you forgot the password), ssh back into the system and run <code>vncpasswd</code> (Currently, vncpasswd will only allow up to 8 characters, unlike regular login passwords.)

* Look for the line indicating a new desktop... '''New ''ugradx'':1 (''joeuser'') desktop is ugradx:1''' (or something similar.)

* Notice what the number after the colon is. e.g. '''''ugradx'':1''' We'll call the number following the ''':''' the ''display number''. You might see a different number. That's ok. You'll need the display number you get for next step.

* '''''Add''''' the display number you noticed in the prior step to value of '''5900''' to create a new port number for vncserver to use in later steps. For example, using ''':1''' from the previous step, add that value of '''''1''''' to '''5900''' to get the new value of '''5901'''. This is a port number, and we'll need this during the upcoming "tunneling-through-ssh" section.

== STEP 2: Tunneling Your VNC Session through SSH ==

You must tunnel your VNC session through SSH for remote access to our our CS Linux computers so that your session is secured. To connect to the remote linux system, you will have to set up an SSH TCP tunnel to the port the server is listening on. That port number is '''5900''' '''''plus the X display number,''''' so it will most often be port '''5901''', as in our earlier example.

The following steps to set up tunneling should work with Windows, Mac, and Linux clients.

On your '''local''' system:

* Open a new terminal ('''but also leaving the ''other'' terminal you ran earlier to start "vncserver" still open and running'''.)

* From the new terminal, run '''ssh -L 5901:localhost:5901 ''joeuser''@''ugradx''.cs.jhu.edu''' and log in as you normally would to ''ugradx''. (Remember, use the port number you came up with in the earlier steps.)

The tunnel is now set. Onto starting the vnc-type client on your local system...

== STEP 3: Starting the VNC client on your Local system==

 
'''''IMPORTANT:'' Leave those ''two'' ssh sessions from earlier running.'''

===Starting a Windows or Linux VNC Client===

* Open your Windows or Linux VNC client on your local system. (If you don't have a VNC client, try [http://www.tigervnc.com/ TigerVNC] and the following steps will assume you're using TigerVNC.)

* Connect to "localhost:1", where ":1" is the actual display number used by your VNC server. You might've used a different display number in earlier steps. And for this step, you do not need the ''590x'' part when inputting the port number in this step..

* Type in the password you gave when setting up the VNC server for ugradx

* You are now connected, with the remote ugradx desktop now displayed securely on your local desktop.

===Starting a Mac VNC Client===
* Point your mouse on the Mac desktop (not on a mac app or window), and click to make sure the desktop is activated.

* Press '''⌘ k'''

* A ''Connect to Server'' window pops up.

* In the empty field, type in the following: '''vnc://localhost:5901''' (or whichever ''port number'' you calculated from an earlier step.)

* A ''Screen Sharing'' window will open.

* Type in the password you gave when setting up the VNC server for ugradx

* You are now connected, with the remote ugradx desktop now displayed securely on your local desktop.

== STEP 4: ''IMPORTANT:'' When you are finished with your VNC connection...==

* Choose either ssh terminal window for which you have a connection to ''ugradx''

* Run: <code>vncserver -kill :1</code> (for the :number, use the display number from the earlier steps. {{red|And make sure you have a space between the ''-kill'' and the '':port #''}})

* Close your VNC client on your local system.

* Close your SSH terminals.

[[Category:Linux Clients]]
[[Category:Software]]
[[Category:Networking]]
[[Category:SSH]]

Using VNC To Access CS Linux Computers

2026-09-29T15:02:32Z

Steve410:

VNC ([https://en.wikipedia.org/wiki/Virtual_Network_Computing Virtual Network Computing]) is supported as a method for remotely accessing our [[:Category:Linux Clients|Linux Clients]]. Because VNC does not, by default, provide a securely encrypted network connection, you will need to tunnel your connections through SSH. Instructions for doing so are below.

Please keep in mind that our Linux clients are for everyone's use and graphical programs can use many system resources. Do not leave VNC sessions running unless you're actively using them. We reserve the right to terminate idle sessions in order to free up resources for others' use.

'''In the examples used below, we want to view the desktop of the remote system, ''ugradx'' by connecting as user ''joeuser''.'''

== STEP 1: Starting the VNC Service on the Remote Computer ==

To start a VNC server on the remote Linux system from your own Windows, Mac,or Linux system:

*Open Windows Powershell, Mac Terminal or Linux shell

* ssh ''joeuser''@''ugradx''.cs.jhu.edu

* run “vncserver”

::'''NOTE:''' If this is the ''first time you're running vncserver'', the first thing it will do is prompt you to enter a new password that will be used in later steps when accessing from a vnc client. You will also be asked if this new password is for view-only. You may say "n" for "no". (Note that the password is needed because of the way VNC works.

:: Anyone who can log in to the system can connect to ''any'' VNC session running on the system, regardless of who started that session. The password ensures that only you can use your sessions.)

::At a later time, should you need to reset your vnc password (e.g., you forgot the password), ssh back into the system and run <code>vncpasswd</code> (Currently, vncpasswd will only allow up to 8 characters, unlike regular login passwords.)

* Look for the line indicating a new desktop... '''New ''ugradx'':1 (''joeuser'') desktop is ugradx:1''' (or something similar.)

* Notice what the number after the colon is. e.g. '''''ugradx'':1''' We'll call the number following the ''':''' the ''display number''. You might see a different number. That's ok. You'll need the display number you get for next step.

* '''''Add''''' the display number you noticed in the prior step to value of '''5900''' to create a new port number for vncserver to use in later steps. For example, using ''':1''' from the previous step, add that value of '''''1''''' to '''5900''' to get the new value of '''5901'''. This is a port number, and we'll need this during the upcoming "tunneling-through-ssh" section.

== STEP 2: Tunneling Your VNC Session through SSH ==

You must tunnel your VNC session through SSH for remote access to our our CS Linux computers so that your session is secured. To connect to the remote linux system, you will have to set up an SSH TCP tunnel to the port the server is listening on. That port number is '''5900''' '''''plus the X display number,''''' so it will most often be port '''5901''', as in our earlier example.

The following steps to set up tunneling should work with Windows, Mac, and Linux clients.

On your '''local''' system:

* Open a new terminal ('''but also leaving the ''other'' terminal you ran earlier to start "vncserver" still open and running'''.)

* From the new terminal, run '''ssh -L 5901:localhost:5901 ''joeuser''@''ugradx''.cs.jhu.edu''' and log in as you normally would to ''ugradx''. (Remember, use the port number you came up with in the earlier steps.)

The tunnel is now set. Onto starting the vnc-type client on your local system...

== STEP 3: Starting the VNC client on your Local system==

 
'''''IMPORTANT:'' Leave those ''two'' ssh sessions from earlier running.'''

===Starting a Windows or Linux VNC Client===

* Open your Windows or Linux VNC client on your local system. (If you don't have a VNC client, try [http://www.tigervnc.com/ TigerVNC] and the following steps will assume you're using TigerVNC.)

* Connect to "localhost:1", where ":1" is the actual display number used by your VNC server. You might've used a different display number in earlier steps. And for this step, you do not need the ''590x'' part when inputting the port number in this step..

* Type in the password you gave when setting up the VNC server for ugradx

* You are now connected, with the remote ugradx desktop now displayed securely on your local desktop.

===Starting a Mac VNC Client===
* Point your mouse on the Mac desktop (not on a mac app or window), and click to make sure the desktop is activated.

* Press '''⌘ k'''

* A ''Connect to Server'' window pops up.

* In the empty field, type in the following: '''vnc://localhost:5901''' (or whichever ''port number'' you calculated from an earlier step.)

* A ''Screen Sharing'' window will open.

* Type in the password you gave when setting up the VNC server for ugradx

* You are now connected, with the remote ugradx desktop now displayed securely on your local desktop.

== STEP 4: ''IMPORTANT:'' When you are finished with your VNC connection...==

* Choose either ssh terminal window for which you have a connection to ''ugradx''

* Run: <code>vncserver -kill :1</code> (for the :number, use the display number from the earlier steps. {{red|And make sure you have a space between the ''-kill'' and the '':port #''}})

* Close your VNC client on your local system.

* Close your SSH terminals.

[[Category:Linux Clients]]
[[Category:Software]]
[[Category:Networking]]
[[Category:SSH]]

Using VNC To Access CS Linux Computers

2026-09-29T15:01:27Z

Steve410: /* Tunneling Your VNC Session through SSH */

VNC ([https://en.wikipedia.org/wiki/Virtual_Network_Computing Virtual Network Computing]) is supported as a method for remotely accessing our [[:Category:Linux Clients|Linux Clients]]. Because VNC does not, by default, provide a securely encrypted network connection, you will need to tunnel your connections through SSH. Instructions for doing so are below.

Please keep in mind that our Linux clients are for everyone's use and graphical programs can use many system resources. Do not leave VNC sessions running unless you're actively using them. We reserve the right to terminate idle sessions in order to free up resources for others' use.

'''In the examples used below, we want to view the desktop of the remote system, ''ugradx'' by connecting as user ''joeuser''.'''

== STEP 1: Starting the VNC Service on the Remote Computer ==

To start a VNC server on the remote Linux system from your own Windows, Mac,or Linux system:

*Open Windows Powershell, Mac Terminal or Linux shell

* ssh ''joeuser''@''ugradx''.cs.jhu.edu

* run “vncserver”

::'''NOTE:''' If this is the ''first time you're running vncserver'', the first thing it will do is prompt you to enter a new password that will be used in later steps when accessing from a vnc client. You will also be asked if this new password is for view-only. You may say "n" for "no". (Note that the password is needed because of the way VNC works.

:: Anyone who can log in to the system can connect to ''any'' VNC session running on the system, regardless of who started that session. The password ensures that only you can use your sessions.)

::At a later time, should you need to reset your vnc password (e.g., you forgot the password), ssh back into the system and run <code>vncpasswd</code> (Currently, vncpasswd will only allow up to 8 characters, unlike regular login passwords.)

* Look for the line indicating a new desktop... '''New ''ugradx'':1 (''joeuser'') desktop is ugradx:1''' (or something similar.)

* Notice what the number after the colon is. e.g. '''''ugradx'':1''' We'll call the number following the ''':''' the ''display number''. You might see a different number. That's ok. You'll need the display number you get for next step.

* '''''Add''''' the display number you noticed in the prior step to value of '''5900''' to create a new port number for vncserver to use in later steps. For example, using ''':1''' from the previous step, add that value of '''''1''''' to '''5900''' to get the new value of '''5901'''. This is a port number, and we'll need this during the upcoming "tunneling-through-ssh" section.

== STEP 2: Tunneling Your VNC Session through SSH ==

You must tunnel your VNC session through SSH for remote access to our our CS Linux computers so that your session is secured. To connect to the remote linux system, you will have to set up an SSH TCP tunnel to the port the server is listening on. That port number is '''5900''' '''''plus the X display number,''''' so it will most often be port '''5901''', as in our earlier example.

The following steps to set up tunneling should work with Windows, Mac, and Linux clients.

On your '''local''' system:

* Open a new terminal ('''but also leaving the ''other'' terminal you ran earlier to start "vncserver" still open and running'''.)

* From the new terminal, run '''ssh -L 5901:localhost:5901 ''joeuser''@''ugradx''.cs.jhu.edu''' and log in as you normally would to ''ugradx''. (Remember, use the port number you came up with in the earlier steps.)

The tunnel is now set. Onto starting the vnc-type client on your local system...

== Starting the VNC client on your Local system==

 
'''''IMPORTANT:'' Leave those ''two'' ssh sessions from earlier running.'''

===Starting a Windows or Linux VNC Client===

* Open your Windows or Linux VNC client on your local system. (If you don't have a VNC client, try [http://www.tigervnc.com/ TigerVNC] and the following steps will assume you're using TigerVNC.)

* Connect to "localhost:1", where ":1" is the actual display number used by your VNC server. You might've used a different display number in earlier steps. And for this step, you do not need the ''590x'' part when inputting the port number in this step..

* Type in the password you gave when setting up the VNC server for ugradx

* You are now connected, with the remote ugradx desktop now displayed securely on your local desktop.

===Starting a Mac VNC Client===
* Point your mouse on the Mac desktop (not on a mac app or window), and click to make sure the desktop is activated.

* Press '''⌘ k'''

* A ''Connect to Server'' window pops up.

* In the empty field, type in the following: '''vnc://localhost:5901''' (or whichever ''port number'' you calculated from an earlier step.)

* A ''Screen Sharing'' window will open.

* Type in the password you gave when setting up the VNC server for ugradx

* You are now connected, with the remote ugradx desktop now displayed securely on your local desktop.

==''IMPORTANT:'' When you are finished with your VNC connection...==

* Choose either ssh terminal window for which you have a connection to ''ugradx''

* Run: <code>vncserver -kill :1</code> (for the :number, use the display number from the earlier steps. {{red|And make sure you have a space between the ''-kill'' and the '':port #''}})

* Close your VNC client on your local system.

* Close your SSH terminals.

[[Category:Linux Clients]]
[[Category:Software]]
[[Category:Networking]]
[[Category:SSH]]

Using VNC To Access CS Linux Computers

2026-09-29T15:01:13Z

Steve410: /* First Steps... Starting the VNC Service on the Remote Computer */

VNC ([https://en.wikipedia.org/wiki/Virtual_Network_Computing Virtual Network Computing]) is supported as a method for remotely accessing our [[:Category:Linux Clients|Linux Clients]]. Because VNC does not, by default, provide a securely encrypted network connection, you will need to tunnel your connections through SSH. Instructions for doing so are below.

Please keep in mind that our Linux clients are for everyone's use and graphical programs can use many system resources. Do not leave VNC sessions running unless you're actively using them. We reserve the right to terminate idle sessions in order to free up resources for others' use.

'''In the examples used below, we want to view the desktop of the remote system, ''ugradx'' by connecting as user ''joeuser''.'''

== STEP 1: Starting the VNC Service on the Remote Computer ==

To start a VNC server on the remote Linux system from your own Windows, Mac,or Linux system:

*Open Windows Powershell, Mac Terminal or Linux shell

* ssh ''joeuser''@''ugradx''.cs.jhu.edu

* run “vncserver”

::'''NOTE:''' If this is the ''first time you're running vncserver'', the first thing it will do is prompt you to enter a new password that will be used in later steps when accessing from a vnc client. You will also be asked if this new password is for view-only. You may say "n" for "no". (Note that the password is needed because of the way VNC works.

:: Anyone who can log in to the system can connect to ''any'' VNC session running on the system, regardless of who started that session. The password ensures that only you can use your sessions.)

::At a later time, should you need to reset your vnc password (e.g., you forgot the password), ssh back into the system and run <code>vncpasswd</code> (Currently, vncpasswd will only allow up to 8 characters, unlike regular login passwords.)

* Look for the line indicating a new desktop... '''New ''ugradx'':1 (''joeuser'') desktop is ugradx:1''' (or something similar.)

* Notice what the number after the colon is. e.g. '''''ugradx'':1''' We'll call the number following the ''':''' the ''display number''. You might see a different number. That's ok. You'll need the display number you get for next step.

* '''''Add''''' the display number you noticed in the prior step to value of '''5900''' to create a new port number for vncserver to use in later steps. For example, using ''':1''' from the previous step, add that value of '''''1''''' to '''5900''' to get the new value of '''5901'''. This is a port number, and we'll need this during the upcoming "tunneling-through-ssh" section.

== Tunneling Your VNC Session through SSH ==

You must tunnel your VNC session through SSH for remote access to our our CS Linux computers so that your session is secured. To connect to the remote linux system, you will have to set up an SSH TCP tunnel to the port the server is listening on. That port number is '''5900''' '''''plus the X display number,''''' so it will most often be port '''5901''', as in our earlier example.

The following steps to set up tunneling should work with Windows, Mac, and Linux clients.

On your '''local''' system:

* Open a new terminal ('''but also leaving the ''other'' terminal you ran earlier to start "vncserver" still open and running'''.)

* From the new terminal, run '''ssh -L 5901:localhost:5901 ''joeuser''@''ugradx''.cs.jhu.edu''' and log in as you normally would to ''ugradx''. (Remember, use the port number you came up with in the earlier steps.)

The tunnel is now set. Onto starting the vnc-type client on your local system...

== Starting the VNC client on your Local system==

 
'''''IMPORTANT:'' Leave those ''two'' ssh sessions from earlier running.'''

===Starting a Windows or Linux VNC Client===

* Open your Windows or Linux VNC client on your local system. (If you don't have a VNC client, try [http://www.tigervnc.com/ TigerVNC] and the following steps will assume you're using TigerVNC.)

* Connect to "localhost:1", where ":1" is the actual display number used by your VNC server. You might've used a different display number in earlier steps. And for this step, you do not need the ''590x'' part when inputting the port number in this step..

* Type in the password you gave when setting up the VNC server for ugradx

* You are now connected, with the remote ugradx desktop now displayed securely on your local desktop.

===Starting a Mac VNC Client===
* Point your mouse on the Mac desktop (not on a mac app or window), and click to make sure the desktop is activated.

* Press '''⌘ k'''

* A ''Connect to Server'' window pops up.

* In the empty field, type in the following: '''vnc://localhost:5901''' (or whichever ''port number'' you calculated from an earlier step.)

* A ''Screen Sharing'' window will open.

* Type in the password you gave when setting up the VNC server for ugradx

* You are now connected, with the remote ugradx desktop now displayed securely on your local desktop.

==''IMPORTANT:'' When you are finished with your VNC connection...==

* Choose either ssh terminal window for which you have a connection to ''ugradx''

* Run: <code>vncserver -kill :1</code> (for the :number, use the display number from the earlier steps. {{red|And make sure you have a space between the ''-kill'' and the '':port #''}})

* Close your VNC client on your local system.

* Close your SSH terminals.

[[Category:Linux Clients]]
[[Category:Software]]
[[Category:Networking]]
[[Category:SSH]]

Category:Virtual Machines (VMs)

2026-09-08T14:38:49Z

Steve410: /* IMPORTANT Guidelines/Policies For Running A Virtual Machine On CS's VM Server */

==CS Now Hosts VMs For ''Educational Use''==

CS operates a Virtual Machine (VM) server for educational use and some light research. CS faculty, instructors, and students may [[Requesting A Virtual Machine|request a VM]] be created for CS class use and CS-related school projects.

:'''(NOTE: The VM services that CS IT offers are {{red|''not''}} for production systems, but only for projects as described above.)'''

We can support both Linux and Windows-based VMs. (Windows-based VMs might require '''''you''' to obtain'' a license for the Windows OS version you plan to install.)

Please see the ''"Pages in category..."'' list below for pages to help you request and set up a VM on our CS VM server.

{{red|'''''NOTE:''''' Our VM resources will ''not'' allow for a full class of VMs. This service is geared towards individual students wanting to use a VM to help with their schoolwork and will be granted as VM computing resources will allow. Alternatively, a course could have one single VM that multiple students can access, but again, resource-dependent.}}
 

== '''IMPORTANT''' Guidelines/Policies For Running A Virtual Machine On CS's VM Server==

* Our VM service is for CS class use and CS-related school projects. Certain exceptions might be made for short-term, light research VMs.

* Our VM service is {{red|'''not'''}} for ''production'' systems.

* {{red|You will need a CS Faculty "sponsor" for your VM.}} The list of CS Faculty members can be found [https://www.cs.jhu.edu/faculty here]. If your instructor is not on the list at that link, you will still need to get approval from someone specifically at that link.

* '''You''' will supply the CS IT staff with the OS disc (on CD or DVD) that you want installed. Alternatively, you may provide us a link to download the ''ISO'' for the OS you need installed.
** We can support both Linux and Windows-based VMs. (''Windows-based VMs might require '''you''' to obtain a license for the Windows OS version you plan to install.)''
** In certain instances, e.g. Linux distributions, there are some versions we already have available.
** We will discuss with you what we need you to provide.

* '''You''' will be the root/super user/administrator for your VM.
** We (the CS admins) will simply install the basic OS.
**We, or both you and we, will configure the networking on the VM.
** We will supply you with the root/administrator password.
**You may create accounts as needed, however, we must retain a copy of the root/administrator password for your VM.

* '''You''' are responsible for providing any additional OS patches or necessary software applications for your VM.

* '''You''' will need to arrange for any necessary port openings through the JHU Firewall (for connections from outside of JHU to your system within JHU.)
** See [[Requesting Open Ports on the JHU Firewall]].

* We '''do not''' do regular backups of VMs.
** (We generally create a baseline backup of our VMs, and occasionally backup all VM images on the server.)
** You are responsible for backing up any ''system files or data'' created on your VM.

* When your VM is no longer needed (per the length of time info you provide when [[Requesting_A_Virtual_Machine | requesting the VM]]), we may remove the VM without additional notice.

* '''You''' are responsible for any security issues that arise due to your VM.
** We have the right to shut down a VM that is causing any security issues.
** JHU has the right to close any network ports for the IP for your VM.

* Occasionally, we have to do maintenance on the VM server, and we try to notify all VM owners when the server must go down. However, running a VM on our VM server is ''at your own risk'', and there might be times when there is unannounced unavailability of the VM server and its VMs.

* Not all VMs may be approved for installation.



[[Category:All]]

Category:Virtual Machines (VMs)

2026-09-08T14:37:45Z

Steve410: /* CS Now Hosts VMs For Educational Use */

==CS Now Hosts VMs For ''Educational Use''==

CS operates a Virtual Machine (VM) server for educational use and some light research. CS faculty, instructors, and students may [[Requesting A Virtual Machine|request a VM]] be created for CS class use and CS-related school projects.

:'''(NOTE: The VM services that CS IT offers are {{red|''not''}} for production systems, but only for projects as described above.)'''

We can support both Linux and Windows-based VMs. (Windows-based VMs might require '''''you''' to obtain'' a license for the Windows OS version you plan to install.)

Please see the ''"Pages in category..."'' list below for pages to help you request and set up a VM on our CS VM server.

{{red|'''''NOTE:''''' Our VM resources will ''not'' allow for a full class of VMs. This service is geared towards individual students wanting to use a VM to help with their schoolwork and will be granted as VM computing resources will allow. Alternatively, a course could have one single VM that multiple students can access, but again, resource-dependent.}}
 

== '''IMPORTANT''' Guidelines/Policies For Running A Virtual Machine On CS's VM Server==

* Our VM service is for CS class use and CS-related school projects. Certain exceptions might be made for short-term, light research VMs.

* Our VM service is {{red|'''not'''}} for ''production'' systems.

* {{red|You will need a CS Faculty "sponsor" for your VM.}} The list of CS Faculty members can be found [https://www.cs.jhu.edu/faculty here]. If your instructor is not on the list at that link, you will still need to get approval from someone specifically at that link.

* '''You''' will supply the CS IT staff with the OS disc (on CD or DVD) that you want installed. Alternatively, you may provide us a link to download the ''ISO'' for the OS you need installed.
** We can support both Linux and Windows-based VMs. (''Windows-based VMs might require '''you''' to obtain a license for the Windows OS version you plan to install.)''
** In certain instances, e.g. Linux distributions, there are some versions we already have available.
** We will discuss with you what we need you to provide.

* '''You''' will be the root/super user/admin for your VM.
** We (the CS admins) will simply install the basic OS.
**We, or both you and we, will configure the networking on the VM.
** We will supply you with the root/administrator password.
**You may create accounts as needed, however, we must retain a copy of the root/administrator password for your VM.

* '''You''' are responsible for providing any additional OS patches or necessary software applications for your VM.

* '''You''' will need to arrange for any necessary port openings through the JHU Firewall (for connections from outside of JHU to your system within JHU.)
** See [[Requesting Open Ports on the JHU Firewall]].

* We '''do not''' do regular backups of VMs.
** (We generally create a baseline backup of our VMs, and occasionally backup all VM images on the server.)
** You are responsible for backing up any ''system files or data'' created on your VM.

* When your VM is no longer needed (per the length of time info you provide when [[Requesting_A_Virtual_Machine | requesting the VM]]), we may remove the VM without additional notice.

* '''You''' are responsible for any security issues that arise due to your VM.
** We have the right to shut down a VM that is causing any security issues.
** JHU has the right to close any network ports for the IP for your VM.

* Occasionally, we have to do maintenance on the VM server, and we try to notify all VM owners when the server must go down. However, running a VM on our VM server is ''at your own risk'', and there might be times when there is unannounced unavailability of the VM server and its VMs.

* Not all VMs may be approved for installation.



[[Category:All]]

Category:Virtual Machines (VMs)

2026-09-08T14:09:21Z

Steve410: /* IMPORTANT Guidelines/Policies For Running A Virtual Machine On CS's VM Server */

==CS Now Hosts VMs For ''Educational Use''==

CS operates a Virtual Machine (VM) server for educational use and some light research. CS faculty, instructors, and students may [[Requesting A Virtual Machine|request a VM]] be created for CS class use and CS-related school projects.

:'''(NOTE: The VM services that CS IT offers are {{red|''not''}} for production systems, but only for projects as described above.)'''

We can support both Linux and Windows-based VMs. (Windows-based VMs might require '''''you''' to obtain'' a license for the Windows OS version you plan to install.)

Please see the ''"Pages in category..."'' list below for pages to help you request and set up a VM on our CS VM server.

{{red|'''''NOTE:''''' Our VM resources will ''not'' allow for a full class of VMs. This service is geared to individual students wanting to use a VM to help with their schoolwork and will be granted as VM computing resources will allow. Alternatively, a course could have one single VM that multiple students can access, but again, resource-dependent.}}
 

== '''IMPORTANT''' Guidelines/Policies For Running A Virtual Machine On CS's VM Server==

* Our VM service is for CS class use and CS-related school projects. Certain exceptions might be made for short-term, light research VMs.

* Our VM service is {{red|'''not'''}} for ''production'' systems.

* {{red|You will need a CS Faculty "sponsor" for your VM.}} The list of CS Faculty members can be found [https://www.cs.jhu.edu/faculty here]. If your instructor is not on the list at that link, you will still need to get approval from someone specifically at that link.

* '''You''' will supply the CS IT staff with the OS disc (on CD or DVD) that you want installed. Alternatively, you may provide us a link to download the ''ISO'' for the OS you need installed.
** We can support both Linux and Windows-based VMs. (''Windows-based VMs might require '''you''' to obtain a license for the Windows OS version you plan to install.)''
** In certain instances, e.g. Linux distributions, there are some versions we already have available.
** We will discuss with you what we need you to provide.

* '''You''' will be the root/super user/admin for your VM.
** We (the CS admins) will simply install the basic OS.
**We, or both you and we, will configure the networking on the VM.
** We will supply you with the root/administrator password.
**You may create accounts as needed, however, we must retain a copy of the root/administrator password for your VM.

* '''You''' are responsible for providing any additional OS patches or necessary software applications for your VM.

* '''You''' will need to arrange for any necessary port openings through the JHU Firewall (for connections from outside of JHU to your system within JHU.)
** See [[Requesting Open Ports on the JHU Firewall]].

* We '''do not''' do regular backups of VMs.
** (We generally create a baseline backup of our VMs, and occasionally backup all VM images on the server.)
** You are responsible for backing up any ''system files or data'' created on your VM.

* When your VM is no longer needed (per the length of time info you provide when [[Requesting_A_Virtual_Machine | requesting the VM]]), we may remove the VM without additional notice.

* '''You''' are responsible for any security issues that arise due to your VM.
** We have the right to shut down a VM that is causing any security issues.
** JHU has the right to close any network ports for the IP for your VM.

* Occasionally, we have to do maintenance on the VM server, and we try to notify all VM owners when the server must go down. However, running a VM on our VM server is ''at your own risk'', and there might be times when there is unannounced unavailability of the VM server and its VMs.

* Not all VMs may be approved for installation.



[[Category:All]]

Category:Virtual Machines (VMs)

2026-09-08T14:08:16Z

Steve410: /* IMPORTANT Guidelines/Policies For Running A Virtual Machine On CS's VM Server */

==CS Now Hosts VMs For ''Educational Use''==

CS operates a Virtual Machine (VM) server for educational use and some light research. CS faculty, instructors, and students may [[Requesting A Virtual Machine|request a VM]] be created for CS class use and CS-related school projects.

:'''(NOTE: The VM services that CS IT offers are {{red|''not''}} for production systems, but only for projects as described above.)'''

We can support both Linux and Windows-based VMs. (Windows-based VMs might require '''''you''' to obtain'' a license for the Windows OS version you plan to install.)

Please see the ''"Pages in category..."'' list below for pages to help you request and set up a VM on our CS VM server.

{{red|'''''NOTE:''''' Our VM resources will ''not'' allow for a full class of VMs. This service is geared to individual students wanting to use a VM to help with their schoolwork and will be granted as VM computing resources will allow. Alternatively, a course could have one single VM that multiple students can access, but again, resource-dependent.}}
 

== '''IMPORTANT''' Guidelines/Policies For Running A Virtual Machine On CS's VM Server==

* Our VM service is for CS class use and CS-related school projects. Certain exceptions might be made for short-term, light research VMs.

* Our VM service is {{red|'''not'''}} for ''production'' systems.

* {{red|You will need a CS Faculty "sponsor" for your VM.}} The list of CS Faculty members can be found [https://www.cs.jhu.edu/faculty here]. If your instructor is not on the list at that link, you will still need to get approval from someone specifically at that link.

* '''You''' will supply the CS IT staff with the OS disc (on CD or DVD) that you want installed. Alternatively, you may provide us a link to download the ''ISO'' for the OS you need installed.
** We can support both Linux and Windows-based VMs. (''Windows-based VMs might require '''you''' to obtain a license for the Windows OS version you plan to install.)''
** In certain instances, e.g. Linux distributions, there are some versions we already have available.
** We will discuss with you what we need you to provide.

* '''You''' will be the root/super user/admin for your VM.
** We (the CS admins) will simply install the basic OS.
**We, or both you and we, will configure the networking on the VM.
** We will supply you with the root password.
**You may create accounts as needed, however, we must retain a copy of the root password for your VM.

* '''You''' are responsible for providing any additional OS patches or necessary software applications for your VM.

* '''You''' will need to arrange for any necessary port openings through the JHU Firewall (for connections from outside of JHU to your system within JHU.)
** See [[Requesting Open Ports on the JHU Firewall]].

* We '''do not''' do regular backups of VMs.
** (We generally create a baseline backup of our VMs, and occasionally backup all VM images on the server.)
** You are responsible for backing up any ''system files or data'' created on your VM.

* When your VM is no longer needed (per the length of time info you provide when [[Requesting_A_Virtual_Machine | requesting the VM]]), we may remove the VM without additional notice.

* '''You''' are responsible for any security issues that arise due to your VM.
** We have the right to shut down a VM that is causing any security issues.
** JHU has the right to close any network ports for the IP for your VM.

* Occasionally, we have to do maintenance on the VM server, and we try to notify all VM owners when the server must go down. However, running a VM on our VM server is ''at your own risk'', and there might be times when there is unannounced unavailability of the VM server and its VMs.

* Not all VMs may be approved for installation.



[[Category:All]]