CS IT Support Wiki - User contributions [en]

Bug Reporting

2019-02-22T18:26:30Z

Phil.cs.jhu.edu: Undo revision 5209 by Phil.cs.jhu.edu (talk)

To report a bug on any of our Linux or Windows client systems, please ''completely'' fill out the [http://support.cs.jhu.edu/forms/bug-report-form Bug Report Form] which can also be found on our [[Forms]] page.

If the problem you're experiencing does not seem to be a bug, but rather, a "how-to" question, please e-mail [mailto:support@cs.jhu.edu support@cs.jhu.edu] instead.

[[Category:Computers Available on the CS Network]]
[[Category:Linux Clients]]
[[Category:Troubleshooting]]

Bug Reporting

2019-02-22T18:26:05Z

Phil.cs.jhu.edu:

#REDIRECT [https://support.cs.jhu.edu/forms/bug-report-form]

[[Category:Computers Available on the CS Network]]
[[Category:Linux Clients]]
[[Category:Troubleshooting]]

Notices

2019-02-14T17:22:12Z

Phil.cs.jhu.edu: /* PLANNED CS SERVICE OUTAGES */

== SERVICE OUTAGES ==
 


=== UNPLANNED CS SERVICE OUTAGES ===

;'''WHAT'''
:MH 122: ugrad1 cannot display anything on the projector
;'''WHEN'''
:Since February 2019
;'''DETAILS'''
:Communication between ugrad1 and the projector does not currently work. We're waiting on a fix from the manufacturer of our A/V system. You ''can'' still connect a laptop to the projector using the instructions available at the table.



 

=== PLANNED CS SERVICE OUTAGES ===

:None at this time.

















== CS COMPUTING LAB AVAILABILITY ==


 
: All CS computing labs available at this time.










[[Category:All]]

Notices

2019-02-13T19:51:15Z

Phil.cs.jhu.edu: /* SERVICE OUTAGES */

== SERVICE OUTAGES ==
 


=== UNPLANNED CS SERVICE OUTAGES ===

;'''WHAT'''
:MH 122: ugrad1 cannot display anything on the projector
;'''WHEN'''
:Since February 2019
;'''DETAILS'''
:Communication between ugrad1 and the projector does not currently work. We're waiting on a fix from the manufacturer of our A/V system. You ''can'' still connect a laptop to the projector using the instructions available at the table.



 

=== PLANNED CS SERVICE OUTAGES ===



;'''WHAT'''
:Hardware replacement on ugrad8, ugrad19, and ugrad22
;'''WHEN'''
:February 13th from 9:00am until 5:00pm
;'''DETAILS'''
:All three systems have hardware that needs to be replaced. They will be offline until the replacements are complete.

















== CS COMPUTING LAB AVAILABILITY ==


 
: All CS computing labs available at this time.










[[Category:All]]

Notices

2019-02-13T18:29:51Z

Phil.cs.jhu.edu: /* PLANNED CS SERVICE OUTAGES */

== SERVICE OUTAGES ==
 


=== UNPLANNED CS SERVICE OUTAGES ===


:None at this time.
 

=== PLANNED CS SERVICE OUTAGES ===



;'''WHAT'''
:Hardware replacement on ugrad8, ugrad19, and ugrad22
;'''WHEN'''
:February 13th from 9:00am until 5:00pm
;'''DETAILS'''
:All three systems have hardware that needs to be replaced. They will be offline until the replacements are complete.

















== CS COMPUTING LAB AVAILABILITY ==


 
: All CS computing labs available at this time.










[[Category:All]]

Notices

2019-02-12T14:55:00Z

Phil.cs.jhu.edu: /* PLANNED CS SERVICE OUTAGES */

== SERVICE OUTAGES ==
 


=== UNPLANNED CS SERVICE OUTAGES ===


:None at this time.
 

=== PLANNED CS SERVICE OUTAGES ===



;'''WHAT'''
:Hardware replacement on ugrad8, ugrad19, and ugrad22
;'''WHEN'''
:February 13th from 9:00am until 3:00pm
;'''DETAILS'''
:All three systems have hardware that needs to be replaced. They will be offline until the replacements are complete.

















== CS COMPUTING LAB AVAILABILITY ==


 
: All CS computing labs available at this time.










[[Category:All]]

Lab And Other Website Hosting

2019-02-04T15:07:12Z

Phil.cs.jhu.edu: Created page with "In addition to hosting personal webpages accessed as <code><nowiki>http://www.cs.jhu.edu</nowiki>/~<var>account</var></code>, we can also host entire we..."

In addition to hosting [[Creating a Webpage|personal webpages]] accessed as <code><nowiki>http://www.cs.jhu.edu</nowiki>/~<var>account</var></code>, we can also host entire websites, with custom URLs (e.g. <code><nowiki>http://</nowiki><var>your-lab-name</var>.cs.jhu.edu</code>).

This service is only available to CS Faculty.

To request a hosted website, you must decide on a website name and storage method for the website files. Both choices are described below. Then you need to email [mailto:support@cs.jhu.edu support@cs.jhu.edu] with your request. If you choose the "dedicated account" storage option, you'll also need to fill out and sign a [https://support.cs.jhu.edu/forms/vhost-form.pdf website account form].

== Website Name Options ==

This choice governs what URLs people use for accessing your website. There are three options available.

=== CS Domain Name ===

Your website name can exist under the <code>cs.jhu.edu</code> domain, e.g. <code><var>your-lab</var>.cs.jhu.edu</code>.

If you request this option, we will set it up for you when we set up your website.

=== JHU Domain Name ===

You can also set up a website name within the <code>jhu.edu</code> domain, e.g. <code><var>your-lab</var>.jhu.edu</code>.

We cannot set this up for you automatically. If you want this option, we'll put you in contact with the appropriate people who manage the <code>jhu.edu</code> domain; you'll have to request the name from them.

=== Other Domain Name ===

Finally, you can use any second-level domain you want to register, e.g. <code><var>your-lab</var>.org</code>.

If you chose this option, you will be entirely responsible for making and maintaining the domain registration.

== File Storage Method ==

There are two options for how the website's files will be stored on our systems. Both require CS Linux accounts.

=== Personal Account ===

The simplest approach is to simply store the website's files under your personal CS account. In this case, you create a directory to hold the files (e.g. <code>~/<var>my-lab-website</var></code>) and just tell us what directory you want to use.

This approach works best if you are the only person who will be managing the files for the website.

=== Dedicated Website Account ===

Alternately, we can create a special account dedicated to your website. It will have its own home directory for the website's files. You and anyone else who manages the files will be given access to the account's home directory.

For this option, you will need to fill out and sign a [https://support.cs.jhu.edu/forms/vhost-form.pdf website account form].

This approach is best when more than one person needs to be able to manage the website's files, or when the person managing those files will change over time.

[[Category:Webpages and Webservices]]

Notices

2019-01-25T23:47:33Z

Phil.cs.jhu.edu: /* PLANNED CS SERVICE OUTAGES */

== SERVICE OUTAGES ==
 


=== UNPLANNED CS SERVICE OUTAGES ===


:None at this time.
 

=== PLANNED CS SERVICE OUTAGES ===



;'''WHAT'''
:Upgrades on the CS lab machines and compute systems.
;'''WHEN'''
:January 23rd through 25th and 28th
;'''UPDATE 2019-01-25 19:00'''
:As of January 25th, not all of the systems have been upgraded, so upgrades will continue on Monday the 28th.
:
:gradz and ugradz have not been upgraded. gradx and ugradx have been upgraded, but experienced complications that might require some downtime on Monday to fix. All other systems (masters1 through masters16 and ugrad1 through ugrad24) have been fully upgraded and are available for both local and remote use.
;'''DETAILS'''
:Over the course of three days, various of the lab systems (masters1 through masters16 and ugrad1 through ugrad24) and compute systems (gradx, gradz, ugradx, and ugradz) will be unavailable as they're upgraded from Fedora 27 to Fedora 29.
:
:All systems whose number is an integer multiple of five (masters5, masters10, masters15, ugrad5, ugrad10, ugrad15, and ugrad20) have already been upgraded and should remain available during this time window.

















== CS COMPUTING LAB AVAILABILITY ==


 
: All CS computing labs available at this time.










[[Category:All]]

Notices

2019-01-23T13:50:03Z

Phil.cs.jhu.edu: /* PLANNED CS SERVICE OUTAGES */

== SERVICE OUTAGES ==
 


=== UNPLANNED CS SERVICE OUTAGES ===


:None at this time.
 

=== PLANNED CS SERVICE OUTAGES ===



;'''WHAT'''
:Upgrades on the CS lab machines and compute systems.
;'''WHEN'''
:January 23rd through 25th
;'''DETAILS'''
:Over the course of three days, various of the lab systems (masters1 through masters16 and ugrad1 through ugrad24) and compute systems (gradx, gradz, ugradx, and ugradz) will be unavailable as they're upgraded from Fedora 27 to Fedora 29.
:
:All systems whose number is an integer multiple of five (masters5, masters10, masters15, ugrad5, ugrad10, ugrad15, and ugrad20) have already been upgraded and should remain available during this time window.

















== CS COMPUTING LAB AVAILABILITY ==


 
: All CS computing labs available at this time.










[[Category:All]]

Notices

2019-01-17T15:21:50Z

Phil.cs.jhu.edu: /* PLANNED CS SERVICE OUTAGES */

== SERVICE OUTAGES ==
 


=== UNPLANNED CS SERVICE OUTAGES ===


:None at this time.
 

=== PLANNED CS SERVICE OUTAGES ===

:None at this time.

















== CS COMPUTING LAB AVAILABILITY ==


 
: All CS computing labs available at this time.










[[Category:All]]

Notices

2019-01-17T15:21:42Z

Phil.cs.jhu.edu: /* PLANNED CS SERVICE OUTAGES */

== SERVICE OUTAGES ==
 


=== UNPLANNED CS SERVICE OUTAGES ===


:None at this time.
 

=== PLANNED CS SERVICE OUTAGES ===

None at this time.

















== CS COMPUTING LAB AVAILABILITY ==


 
: All CS computing labs available at this time.










[[Category:All]]

Notices

2019-01-10T15:01:06Z

Phil.cs.jhu.edu: /* PLANNED CS SERVICE OUTAGES */

== SERVICE OUTAGES ==
 


=== UNPLANNED CS SERVICE OUTAGES ===


:None at this time.
 

=== PLANNED CS SERVICE OUTAGES ===



;'''WHAT'''
:Work on one of the CS Department's UPSes
;'''WHEN'''
:Thursday, January 10th starting at 9:00 am
;'''UPDATE'''
:As of 10:00 am on Thursday, January 10th the work has been completed.
;'''DETAILS'''
:We will be performing work on a UPS that provides power to several of the department's servers. The UPS is one of a pair of redundant UPSes and, since the other UPS will remain in place, no visible impact is expected.

















== CS COMPUTING LAB AVAILABILITY ==


 
: All CS computing labs available at this time.










[[Category:All]]

Notices

2019-01-09T20:04:58Z

Phil.cs.jhu.edu: /* PLANNED CS SERVICE OUTAGES */

== SERVICE OUTAGES ==
 


=== UNPLANNED CS SERVICE OUTAGES ===


:None at this time.
 

=== PLANNED CS SERVICE OUTAGES ===



;'''WHAT'''
:Work on one of the CS Department's UPSes
;'''WHEN'''
:Thursday, January 10th starting at 9:00 am
;'''DETAILS'''
:We will be performing work on a UPS that provides power to several of the department's servers. The UPS is one of a pair of redundant UPSes and, since the other UPS will remain in place, no visible impact is expected.

















== CS COMPUTING LAB AVAILABILITY ==


 
: All CS computing labs available at this time.










[[Category:All]]

Using a Static IP Address on the CS Grad Nets

2019-01-07T20:22:05Z

Phil.cs.jhu.edu:

If you have [[Requesting a Static IP Address on the CS Network|requested a static IP address]] and been given one, here is how to use it on the CS networks.

== Plug in to the Network ==

Your IP address is on either the public grad net or the private grad net, depending on what you initially requested. (See [[Networking at CS - Overview]] for more information about our networks.) You must plug your system into an appropriate network jack for the network:

* For '''public''' addresses, use '''even-numbered''' jacks.
* For '''private''' addresses, use '''odd-numbered''' jacks.

If there are insufficient network jacks with the appropriate numbers in your area, please email [mailto:support@cs.jhu.edu support@cs.jhu.edu] with the numbered jacks available to you and we'll see about getting one of them onto the appropriate network.

== Configure Your Computer ==

=== With DHCP ===

If you're using DHCP, which we recommend, and you indicated that use in your request, you should be able to just plug your system into the network and have it work. If your MAC address changes (e.g. you get a new computer or just a new NIC), you'll have to fill out the [http://support.cs.jhu.edu/forms/ip-address-application CS Network IP Address Application] again and mark it at the top as a modification of an existing allocation.

=== With Manual Configuration ===

If you want to set your system up manually (and we recommend that you use DHCP instead), here's the information you need.

==== On the Private Grad/Research Net ====

If you have an address on the private net, use the following settings:

* '''IP Address''': The address given to you by the CS IT group.
* '''Netmask''': 255.255.255.0
* '''Default Gateway''': 10.161.159.1
* '''Nameservers''': 10.200.1.1 and 10.200.2.2
* '''Search Domain''': cs.jhu.edu
* '''NTP Servers''': ntp1.jhu.edu, ntp2.jhu.edu (NTP servers are optional.)

==== On the Public Grad/Research Net ====

If you have an address on the public net, use the following settings:

* '''IP Address''': The address given to you by the CS IT group.
* '''Netmask''': 255.255.255.0
* '''Default Gateway''': 128.220.35.1
* '''Nameservers''': 10.200.1.1 and 10.200.2.2
* '''Search Domain''': cs.jhu.edu
* '''NTP Servers''': ntp1.jhu.edu, ntp2.jhu.edu (NTP servers are optional.)

== Open Ports on the JHU Firewall (Optional) ==

If you have a public IP address, you will probably want to have some of its services available to people outside the Hopkins network. To accomplish that, you'll need to follow the instructions in [[Requesting Open Ports on the JHU Firewall]].

== When Your Information Changes ==

If something about the system changes, like its MAC address or your faculty sponsor, please fill out the [http://support.cs.jhu.edu/forms/ip-address-application CS Network IP Address Application] again and select "Modify" at the top of the form.

== When You're Done with the Address ==

When you no longer need this IP address, please fill out the [http://support.cs.jhu.edu/forms/ip-address-application CS Network IP Address Application] one last time and select "Delete" at the top of the form.

== Troubleshooting ==

If your even-numbered network jack provides a private IP instead of public, or if your odd-numbered network jack provides a public IP instead of private, '''''or''''' you don't seem to have any network activity coming from your network jack, please email [mailto:support@cs.jhu.edu support@cs.jhu.edu], and we will investigate further.

[[Category:Networking]]

Networking at CS - Overview

2019-01-07T20:20:56Z

Phil.cs.jhu.edu: No more recursive DNS requests from blaze.

There are three main networks in CS at Malone Hall. They are:

:'''Public CS Grad/Research Net''' (128.220.35.x) - Uses IP addresses that are ''accessible from the Internet''.

:'''Private CS Grad/Research Net''' (10.161.159.x) - Uses IP addresses that are ''only accessible from within the Hopkins network (and Hopkins VPN)''.

:'''CS Undergrad Net''' (128.220.224.x) - Uses IP addresses that are ''accessible from the Internet''

The two Grad/Research nets are only accessible via network jacks in Malone Hall in CS work areas, except for the CS Undergrad Labs (Malone Hall 122 and the Ugrad Lab side of MH G61). The CS Undergrad Net is only accessible via network jacks in the CS Undergrad Lab.

 

==Network Jacks (Wallports) In Malone Hall==

Network jacks may be located be under floor panels via access doors on the floor or they might be located on the wall, depending upon where you're located. Each network jack is identified with a floor number and jack number. (It is very important that any correspondence with CS IT Support or JHU Networking about a network jack include the full jack number.)

(For those grad students working on the third floor of Malone, you might see that your floor panel access door is located under a slightly raised cabinet where the floor access door might be difficult to reach. For your convenience, there are network cables already coming out of those specific floor panels, and each of those cables is labeled with the port number.)

Each network jack in your Malone ''office'' will go to exactly one of those two Grad/Research networks (Public ''or'' Private Grad Net), so care will be needed to connect your computers into appropriate jacks.

Any given network jack can be changed from one network to the other (i.e., ''public to private'' or ''private to public'') with relatively little difficulty with an emailed request to [mailto:support@cs.jhu.edu CS Support]. We will pass on your request to JHU Networking. JHU Networking will be administering the network configurations; here is their current plan:

* '''Even-numbered jacks''', by default, are connected to the '''''Public''''' CS Grad network, 128.220.35.x
* '''Odd-numbered jacks''', by default, are be connected to the '''''Private''''' CS Grad network, 10.161.159.x

'''Note 1:''' All network jacks in the CS Undergrad Lab are part of the CS Undergrad Net (128.220.224.x)

'''Note 2:''' If you have a system that will reside in the G29 Malone ''server room'' instead, please contact CS Support, and we will help arrange your system's connections to the appropriate network, as there are no wallports in G-29.

 

== ''Public'' CS Grad/Research Network Details ==

The '''"Public" CS Grad/Research Net''' uses IP addresses that are directly accessible from the Internet. It is useful for servers that need to be widely accessible or for systems that people need to connect to without going through the Hopkins VPN. (For example, if you need to ssh into your work machine from out on the Internet, your work machine needs a public IP address.)

Systems on the Public Grad Net can freely communicate with systems elsewhere on the Hopkins network, including systems on the Private CS Grad Net.

In order to set up a system on the Public Grad Net, you will need to follow the instructions at [[Requesting a Static IP Address on the CS Network]] and indicate in your request that the IP address will be public. There is '''no''' ''dynamic IP address service'' available on the Public network.

===Public IP Security Considerations===

Please keep in mind that a system with a Public IP is exposed to the Internet. That means that '''''your system is open and vulnerable to access attempts from the outside.''''' If you're the only one who will access your system from the outside, please consider a Private IP instead, and use the VPN to put you into the JHU network so that you can access your system. If you have several outside people needing access to your system, then, yes, a Public IP is probably needed.

And, because systems on the Public Grad Net are exposed to the Internet, they are expected to be managed in a way that preserves their security and the security of the Hopkins network. The JHU Network Security Team (part of the [http://www.it.jhu.edu/ IT@JH] group, ''not'' CS) may periodically perform security scans of systems on the Public Grad Net. If they determine that there are security problems with a system, they may disable all Internet access for that system until the problems are resolved.

 

== ''Private'' CS Grad/Research Network Details==

The '''"Private" CS Grad/Research Net''' uses IP addresses that can only be directly accessed from either the Hopkins network or the Hopkins VPN. It is useful for systems that do not need to be accessed from the Internet, like desktop computers or printers. The private addressing used on this network helps keep the systems a little more secure, since no one on the Internet can contact them directly.

You can connect your system to the Private Grad Net by following the instructions at [[Connecting to the CS Grad Nets]]. By default, you will receive a ''dynamic IP address''. If you need a ''static IP address'', follow the instructions at [[Requesting a Static IP Address on the CS Network]], making sure to specify that you want a ''private static IP address''.

 

==''CS Undergrad Network'' Details==

The '''CS Undergrad Network''' is only available via wall and tabletop network jacks in Malone Hall Room 122 (the CS Collaboration Room). (Note that our other Ugrad Lab room, the Ugrad Lab side of Malone Hall G61, houses additional Ugrad Lab systems, but we are not currently supporting users plugging into the network in that room). To connect to the CS Undergrad Net, follow the instructions at [[Connecting to the CS Ugrad Net]]. Your computer will receive a dynamic IP address. There are no static IP addresses granted for the CS Ugrad Net.

 

== Requesting a Static IP Address ==

If you need to request a ''static IP address'', please follow the instructions at [[Requesting a Static IP Address on the CS Network]].

 

== DNS Servers to use when on the CS Network ==

Primary DNS: '''10.200.1.1'''

Secondary DNS: '''10.200.2.2'''

DHCP-provided CS IPs will automatically receive the above DNS servers.

 

== General Configuration Notes ==

===Public Network (128.220.35.x, even-numbered ports)===

Subnet Mask: '''255.255.255.0'''

Gateway: '''128.220.35.1'''

===Private Network (10.161.159.x, odd-numbered ports)===

Subnet Mask: '''255.255.255.0'''

Gateway: '''10.161.159.1'''

 

== Security Note ==

All computers that connect to the CS Grad/Research or Undergrad net should be at their latest security levels and should be configured to prevent viruses, etc. For antivirus software, please see the [http://it.jhu.edu/antivirus JHU Antivirus webpage].

[[Category:Networking]]

Mail Folder Locations

2018-12-20T21:10:37Z

Phil.cs.jhu.edu: /* Switching from an IMAP Prefix to a Mailbox Subdirectory */

If you only check your mail through IMAP or POP (as documented on our [[:Category:Receiving Email|Receiving Email]] page), you don't need to worry about where the mail is actually stored. (With an exception for Grad Net accounts; see [[#Grad Net Mail Folders|that section below]] for details.) If you want to access the files directly (e.g. to set up procmail or use Pine directly on your mail folders), here's where they are.

== All Accounts: Two Types of Folders ==

When our server receives email for you, it places that email message in your '''''INBOX'''''. (Unless you [[Forwarding Mail|forward your mail]] or use procmail to put messages into a different folder.)

Your mail client will probably have the capability of moving emails into other folders, or '''''mailboxes'''''. Certain mailboxes often have special meaning for a particular client. For example, many clients store copies of email you've sent in a mailbox named "Sent".

The locations of your INBOX and your other mailboxes vary a little depending on whether you have a ugrad account or a grad net account.

== Ugrad Net Mail Folders ==

Your ''INBOX'' is a single file in <code>/var/spool/mail</code> (on any of our [[Linux Clients on the CS Undergrad Net|Linux clients]]) with a name matching your account name. If your account is "<code>example</code>", your INBOX is <code>/var/spool/mail/example</code>.

Your ''mailboxes'' (think of them as your "mail folders" you would see in your mail client) are in the <code>Mail</code> directory in your home directory. Each mailbox is a separate file.

'''Note''': Some older accounts have their mailboxes in a directory named <code>mail</code> (starting with a lowercase "m"). At this point, however, most people will be using <code>Mail</code> (with an uppercase "M").

== Grad Net Mail Folders ==

Your ''INBOX'' is a single file in <code>/var/spool/mail</code> (on any of our [[Linux Clients on the CS Grad/Research Net|Linux clients]]) with a name matching your account name. If your account is "<code>example</code>", your INBOX is <code>/var/spool/mail/example</code>.

The location of your ''mailboxes'' (think of them as your "mail folders" you would see in your mail client) is controlled by the contents of the <code>.mail_location</code> file in your home directory. If that file is empty or doesn't exist, your ''home directory'' is ''also'' the location of your mailboxes. Otherwise, the first line in that file gives the name of the directory containing your mailboxes. (Lines after the first line are currently ignored, but might be given other meanings in the future.)

Newer accounts have the <code>Mail</code> directory listed in the <code>.mail_location</code> file, so that's where those accounts' mailboxes are. Older accounts don't have a <code>.mail_location</code> file, so their mailboxes are in their home directory.

=== Changing Your Grad Net Mailbox Location ===

If you want to, you can change the location of your mailboxes for your grad net account. This can be particularly useful if you have an older account (with your mailboxes in your home directory) and you have a significant number of files in your home directory that are not mail folders. Many mail clients will try to treat every file in your mailbox directory (i.e. home directory) as a mail folder and will take a long time to look through all of them at times. (This can be mitigated a bit by [[Using IMAP on the Grad/Research Network#Tell the IMAP Server Where Your Mail Folders are Located|setting an IMAP prefix]], but changing your mailbox location is generally a better solution.)

# Decide where you want your mailboxes to be. We recommend <code>Mail</code> for consistency.
# If you have a mail client running, exit it.
# In your home directory, create that <code>Mail</code> directory, if it doesn't already exist.
# Move your current mailboxes into that directory.
# Move your <code>~/.subscriptions</code> file (if you have one) into that directory.
# Edit (or create) a <code>~/.mail_location</code> file and enter your new mailbox directory into it on a single line.
# Restart your mail client and make sure everything looks right.

=== Switching from an IMAP Prefix to a Mailbox Subdirectory ===

Before our separate mailbox definitions were available, we recommended that people put all of their mailboxes into a subdirectory and then set that subdirectory as an [[Using IMAP on the Grad/Research Network#Tell the IMAP Server Where Your Mail Folders are Located|IMAP prefix]]. This setup works, but still has some drawbacks with respect to setting a <code>.mail_location</code> directly. To move from the old setup to the new one:

# If you have a mail client running, exit it.
# If you have some mail folders in your home directory (e.g. "Sent", "Junk"), move them into your mailbox directory.
#* If you're not sure whether you have any such folders, look at your <code>~/.subscriptions</code> file for any folders that aren't in the mailbox directory already.
# Move your <code>~/.subscriptions</code> file (if you have one) into your mailbox directory.
# Edit the <code>.subscriptions</code> file and remove the mailbox directory prefix from your folders.
#* e.g. if your prefix is "<code>Mail</code>", you'd change things like "<code>Mail/seminars</code>" to just "<code>seminars</code>".
# Create a <code>~/.mail_location</code> file and enter your mailbox directory into it on a single line.
# Restart your mail client, remove any IMAP prefix setting, and make sure everything looks right.

[[Category:Receiving Email]]

Mailman at CS

2018-12-18T14:38:59Z

Phil.cs.jhu.edu: /* Spam Management */

Beginning May, 2014, mailing lists at the CS Department are run on [https://wiki.list.org Mailman]. (Older CS mailing lists are [http://www.greatcircle.com/majordomo/ Majordomo]-based.) You can manage your Mailman list memberships from https://www.cs.jhu.edu/mailman for public lists.

For a private list, you'll have to know what the list's name is. The list's name is in the list's email address, so if you send email to and receive email from "''listname@cs.jhu.edu''", the list's name would be "''listname''". You can manage your subscription information for such a list at <tt><nowiki>https://www.cs.jhu.edu</nowiki>/mailman/listinfo/''listname''</tt>.

If you need help with a particular list, you can email <tt>''listname''-owner@cs.jhu.edu</tt> or, as always, [mailto:support@cs.jhu.edu support@cs.jhu.edu]. The [http://www.gnu.org/software/mailman/users.html GNU Mailman User Documentation] may also be helpful.

The rest of this page is mostly concerned with information for list owners; people who run a CS-hosted mailing list.

== Requesting A CS-Hosted Mailing List ==

'''Currently, you must be a CS faculty or staff member (or CS student that has approval from the student's instructor) to request a mailing list.'''

If you need to run a mailing list, please fill out our [http://support.cs.jhu.edu/forms/mailing-list-request mailing list request form]. We will let you know when your new mailing list is ready. We will have some default settings in place for you. The next step is for you to configure/customize your list settings.

== Configuring/Customizing Your New CS Mailing List ==

For purposes of illustration, all of the examples here will use a list named "''listname''".

After we have created your new mailing list, you will receive an email with your list administration password and links to the webpages for managing your mailing list. In general, a list named "''listname''" can be managed from the webpages at <tt><nowiki>https://www.cs.jhu.edu</nowiki>/mailman/admin/''listname''</tt>. You should go there now and make sure it's configured the way you will want it.

=== How Your List is Configured by Default ===

For the most part, the default settings for your list should be reasonable. Specific settings you might want to change are mentioned below.

Broadly speaking, new lists are configured in the following ways by default:

* They're set up as discussion lists, which means that anyone who is subscribed to the list may post to the list and have their post sent to all of the other subscribers. ''Only'' list subscribers can send to the list; non-subscribers will have any attempted posts held until a moderator can review them.
* Lists are largely private by default. They're not advertised publicly (on the [https://www.cs.jhu.edu/mailman/listinfo "list of lists" page]); their archives are only available to list subscribers; and the subscriber list is only available to list moderators.
* Moderator approval is required before anyone can subscribe to the list. Most lists will want to change this setting, but it at least prevents people from using the list until the owner is ready.

=== Things You Should Change ===

On the "General Options" page, which is the first page you'll see when you go to <tt><nowiki>https://www.cs.jhu.edu</nowiki>/mailman/admin/''listname''</tt>, there are a few items you should definitely change:

* '''owner''' - This is your email address and the email addresses of anyone else who will have complete control over the list (if you're sharing list administrative duties).
* '''moderator''' - If you will have list moderators, put their email addresses here. A moderator has less access than a list owner. Moderators can approve postings to the list, clear out spam, and do other housekeeping tasks but cannot reconfigure the list's settings.
* '''description''' - A short (one-line) description of what your mailing list is for.
* '''info''' - A longer description of what your mailing list is for.

=== Things You Might Want to Change ===

Also in the General Options section are these settings, which will probably be okay if you leave them as they are, but which you might want to change to personalize your mailing list:

* '''subject_prefix''' - The text that the mailing list will add to the beginning of the Subject: line for any email sent to the list. We highly recommend that if you have a value here you put it in [square brackets].
* '''welcome_msg''' - This works a bit like the ''info'' field described above, but contains a bit of information that will be sent to any new subscriber to your mailing list. If you want to send welcome messages, you'll also have to set '''send_welcome_msg''' to "Yes".

On the "Privacy Options > Subscription rules" page, you can control how public your mailing list will be. The most notable settings are:

* '''advertised''' - If you set this to "Yes", your mailing list will appear on the list of CS-based lists at https://www.cs.jhu.edu/mailman.
* '''subscribe_policy''' - The default setting, "Require approval", will require you (or a designated list admin or moderator) to approve each subscription request. This maximizes list privacy, but is more work than most lists require. Setting it to "Confirm" allows anyone to subscribe if they want to.

On the "Archiving Options" page, you can control whether Mailman keeps a history of all the emails sent to your list. (Note that nothing can prevent list subscribers from keeping their own archives if they so choose.) The default setting for '''archive_private''', "private", will only allow list subscribers to see the archives. If you change that to "public", anyone on the Internet will be able to see them.

=== Special Settings for Announcement Lists ===

Many lists we host are announcement lists; many people subscribe to these lists, but only a few people have permission to send emails to the list. This is how you set up your mailing list to work similarly:

On the "Privacy options > Sender filters" page (which you get by clicking "Privacy options" in the top menu then clicking "Sender filters"), set the following options:

* '''default_member_moderation''' - Set to "Yes".
* '''member_moderation_notice''' - This is the message that people who are subscribed but not allowed to post will receive if they try to post anyway. We suggest something along the lines of, "This mailing list is only for announcements; you cannot send email to it."
* '''accept_these_nonmembers''' - This is a list of email addresses of people who are allowed to post to the list without being subscribed to it. This would be used for someone who would send messages but who would not necessarily need to receive a copy of every email sent to the list. ('''Note''': This ''only'' works for people who are ''not'' subscribed to the list. For people who are list members, you need to follow the instructions below.)

To allow a list subscriber to send to the list, go to the "Membership Management > Membership List" page, find the entry for the person you want to allow (either by finding them in the table or by putting their email address into the search field and clicking "Search"), uncheck their box in the "mod" column, and click the "Submit Your Changes" button.

== General Mailman Documentation==

There are many additional configuration settings you can change for your Mailman mailing list. You can find general documentation for Mailman at:

:[https://wiki.list.org/DOC/Home https://wiki.list.org/DOC/Home]

== About Passwords ==

===Administrative Password===

: By default, your list has one ''administrative password''. Anyone who knows that password can log in and change anything about your list configuration. This means that the way you give someone access to your list is simply to tell them the password. If you need to remove administrative access for someone, you will have to go to the administrative interface at <tt><nowiki>https://www.cs.jhu.edu</nowiki>/mailman/admin/''listname''</tt>, go to the "Passwords" page, change the administrator password, and then share the new password with anyone else who still needs to have administrative access.

===Moderator Password===

: If you want, you can set a ''moderator password''. Anyone with the moderator password will be able to manage the process of getting emails to or keeping them from the list: they can approve or discard held messages and they can block people from posting to the list. They cannot change much else about the configuration of the list.

===Administrative Interface Password Requests===

: When the ''administrative interface'' asks for a password, either the administrative password or the moderator password can be used. If the moderator password is used, only the moderator functions will be active.

== Spam Management ==

It is a fact of life that eventually someone will try to send spam to your mailing list. Unfortunately, it's also likely that you will eventually have someone who should be allowed to post to the list try to send an email from an email address that the list doesn't recognize. There is no way for Mailman to discriminate between these two scenarios; all it knows is that it got email for a list from someone who isn't affiliated with that list. There are a number of list options available to help you, the list admin, deal with these sorts of situations.

By default, if the mailing list gets an email from someone who isn't subscribed to the list then it will hold on to the email until a list admin or moderator comes along and decides what to do with the email. List admins and moderators will get daily emails with lists of held messages and links to the "pending moderator requests" page (<tt><nowiki>https://www.cs.jhu.edu</nowiki>/mailman/admindb/''listname''</tt>). That page makes it pretty easy to deal with spam. You can easily skim through the list of held emails, click to approve any that should be let through, and then click one button to delete the rest.

On the "General Options" page, the '''admin_immed_notify''' setting can be changed to "Yes", which will send you an email every time a message is held for review. You can reply to that email with instructions for Mailman. This setting is good for people who like using email to manage their list, want fast turnaround for held messages, and don't mind the additional emails.

On the "Privacy options > Sender filters" page, the '''generic_nonmember_action''' setting controls what to do when the list receives an email from an non-subscribed address. The default setting, "Hold", is ''strongly recommended'' so that you can help out people who should be able to send to the list but were blocked for some reason. If, however, you're getting a lot of spam and can live with the future management difficulties, you can set it to "Discard". (The other two settings are ''really'' not recommended for most lists. "Accept" will end up sending a lot of spam to the mailing list, and "Reject" will bother the people that the spammers are pretending to be.)

[[Category:Mailing Lists]]

Mailman at CS

2018-12-18T14:35:36Z

Phil.cs.jhu.edu: /* How Your List is Configured by Default */

Beginning May, 2014, mailing lists at the CS Department are run on [https://wiki.list.org Mailman]. (Older CS mailing lists are [http://www.greatcircle.com/majordomo/ Majordomo]-based.) You can manage your Mailman list memberships from https://www.cs.jhu.edu/mailman for public lists.

For a private list, you'll have to know what the list's name is. The list's name is in the list's email address, so if you send email to and receive email from "''listname@cs.jhu.edu''", the list's name would be "''listname''". You can manage your subscription information for such a list at <tt><nowiki>https://www.cs.jhu.edu</nowiki>/mailman/listinfo/''listname''</tt>.

If you need help with a particular list, you can email <tt>''listname''-owner@cs.jhu.edu</tt> or, as always, [mailto:support@cs.jhu.edu support@cs.jhu.edu]. The [http://www.gnu.org/software/mailman/users.html GNU Mailman User Documentation] may also be helpful.

The rest of this page is mostly concerned with information for list owners; people who run a CS-hosted mailing list.

== Requesting A CS-Hosted Mailing List ==

'''Currently, you must be a CS faculty or staff member (or CS student that has approval from the student's instructor) to request a mailing list.'''

If you need to run a mailing list, please fill out our [http://support.cs.jhu.edu/forms/mailing-list-request mailing list request form]. We will let you know when your new mailing list is ready. We will have some default settings in place for you. The next step is for you to configure/customize your list settings.

== Configuring/Customizing Your New CS Mailing List ==

For purposes of illustration, all of the examples here will use a list named "''listname''".

After we have created your new mailing list, you will receive an email with your list administration password and links to the webpages for managing your mailing list. In general, a list named "''listname''" can be managed from the webpages at <tt><nowiki>https://www.cs.jhu.edu</nowiki>/mailman/admin/''listname''</tt>. You should go there now and make sure it's configured the way you will want it.

=== How Your List is Configured by Default ===

For the most part, the default settings for your list should be reasonable. Specific settings you might want to change are mentioned below.

Broadly speaking, new lists are configured in the following ways by default:

* They're set up as discussion lists, which means that anyone who is subscribed to the list may post to the list and have their post sent to all of the other subscribers. ''Only'' list subscribers can send to the list; non-subscribers will have any attempted posts held until a moderator can review them.
* Lists are largely private by default. They're not advertised publicly (on the [https://www.cs.jhu.edu/mailman/listinfo "list of lists" page]); their archives are only available to list subscribers; and the subscriber list is only available to list moderators.
* Moderator approval is required before anyone can subscribe to the list. Most lists will want to change this setting, but it at least prevents people from using the list until the owner is ready.

=== Things You Should Change ===

On the "General Options" page, which is the first page you'll see when you go to <tt><nowiki>https://www.cs.jhu.edu</nowiki>/mailman/admin/''listname''</tt>, there are a few items you should definitely change:

* '''owner''' - This is your email address and the email addresses of anyone else who will have complete control over the list (if you're sharing list administrative duties).
* '''moderator''' - If you will have list moderators, put their email addresses here. A moderator has less access than a list owner. Moderators can approve postings to the list, clear out spam, and do other housekeeping tasks but cannot reconfigure the list's settings.
* '''description''' - A short (one-line) description of what your mailing list is for.
* '''info''' - A longer description of what your mailing list is for.

=== Things You Might Want to Change ===

Also in the General Options section are these settings, which will probably be okay if you leave them as they are, but which you might want to change to personalize your mailing list:

* '''subject_prefix''' - The text that the mailing list will add to the beginning of the Subject: line for any email sent to the list. We highly recommend that if you have a value here you put it in [square brackets].
* '''welcome_msg''' - This works a bit like the ''info'' field described above, but contains a bit of information that will be sent to any new subscriber to your mailing list. If you want to send welcome messages, you'll also have to set '''send_welcome_msg''' to "Yes".

On the "Privacy Options > Subscription rules" page, you can control how public your mailing list will be. The most notable settings are:

* '''advertised''' - If you set this to "Yes", your mailing list will appear on the list of CS-based lists at https://www.cs.jhu.edu/mailman.
* '''subscribe_policy''' - The default setting, "Require approval", will require you (or a designated list admin or moderator) to approve each subscription request. This maximizes list privacy, but is more work than most lists require. Setting it to "Confirm" allows anyone to subscribe if they want to.

On the "Archiving Options" page, you can control whether Mailman keeps a history of all the emails sent to your list. (Note that nothing can prevent list subscribers from keeping their own archives if they so choose.) The default setting for '''archive_private''', "private", will only allow list subscribers to see the archives. If you change that to "public", anyone on the Internet will be able to see them.

=== Special Settings for Announcement Lists ===

Many lists we host are announcement lists; many people subscribe to these lists, but only a few people have permission to send emails to the list. This is how you set up your mailing list to work similarly:

On the "Privacy options > Sender filters" page (which you get by clicking "Privacy options" in the top menu then clicking "Sender filters"), set the following options:

* '''default_member_moderation''' - Set to "Yes".
* '''member_moderation_notice''' - This is the message that people who are subscribed but not allowed to post will receive if they try to post anyway. We suggest something along the lines of, "This mailing list is only for announcements; you cannot send email to it."
* '''accept_these_nonmembers''' - This is a list of email addresses of people who are allowed to post to the list without being subscribed to it. This would be used for someone who would send messages but who would not necessarily need to receive a copy of every email sent to the list. ('''Note''': This ''only'' works for people who are ''not'' subscribed to the list. For people who are list members, you need to follow the instructions below.)

To allow a list subscriber to send to the list, go to the "Membership Management > Membership List" page, find the entry for the person you want to allow (either by finding them in the table or by putting their email address into the search field and clicking "Search"), uncheck their box in the "mod" column, and click the "Submit Your Changes" button.

== General Mailman Documentation==

There are many additional configuration settings you can change for your Mailman mailing list. You can find general documentation for Mailman at:

:[https://wiki.list.org/DOC/Home https://wiki.list.org/DOC/Home]

== About Passwords ==

===Administrative Password===

: By default, your list has one ''administrative password''. Anyone who knows that password can log in and change anything about your list configuration. This means that the way you give someone access to your list is simply to tell them the password. If you need to remove administrative access for someone, you will have to go to the administrative interface at <tt><nowiki>https://www.cs.jhu.edu</nowiki>/mailman/admin/''listname''</tt>, go to the "Passwords" page, change the administrator password, and then share the new password with anyone else who still needs to have administrative access.

===Moderator Password===

: If you want, you can set a ''moderator password''. Anyone with the moderator password will be able to manage the process of getting emails to or keeping them from the list: they can approve or discard held messages and they can block people from posting to the list. They cannot change much else about the configuration of the list.

===Administrative Interface Password Requests===

: When the ''administrative interface'' asks for a password, either the administrative password or the moderator password can be used. If the moderator password is used, only the moderator functions will be active.

== Spam Management ==

It is a fact of life that eventually someone will try to send spam to your mailing list. Unfortunately, it's also likely that you will eventually have someone who should be allow to post to the list try to send an email from an email address that the list doesn't recognize. There is no way for Mailman to discriminate between these two scenarios; all it knows is that it got email for a list from someone who isn't affiliated with that list. There are a number of list options available to help you, the list admin, deal with these sorts of situations.

By default, if the mailing list gets an email from someone who isn't subscribed to the list then it will hold on to the email until a list admin or moderator comes along and decides what to do with the email. List admins and moderators will get daily emails with lists of held messages and links to the "pending moderator requests" page (<tt><nowiki>https://www.cs.jhu.edu</nowiki>/mailman/admindb/''listname''</tt>). That page makes it pretty easy to deal with spam. You can easily skim through the list of held emails, click to approve any that should be let through, and then click one button to delete the rest.

On the "General Options" page, the '''admin_immed_notify''' setting can be changed to "Yes", which will send you an email every time a message is held for review. You can reply to that email with instructions for Mailman. This setting is good for people who like using email to manage their list, want fast turnaround for held messages, and don't mind the additional emails.

On the "Privacy options > Sender filters" page, the '''generic_nonmember_action''' setting controls what to do when the list receives an email from an non-subscribed address. The default setting, "Hold", is ''strongly recommended'' so that you can help out people who should be able to send to the list but were blocked for some reason. If, however, you're getting a lot of spam and can live with the future management difficulties, you can set it to "Discard". (The other two settings are ''really'' not recommended for most lists. "Accept" will end up sending a lot of spam to the mailing list, and "Reject" will bother the people that the spammers are pretending to be.)

[[Category:Mailing Lists]]

Using Shibboleth

2018-12-13T16:04:11Z

Phil.cs.jhu.edu: /* Option One: Webserver Authorization */

[http://shibboleth.net Shibboleth] is software that allows one website to use another website for login information, so that people who want to log in to a Shibboleth-based site are transparently redirected to a central login site to enter their account name and password and are then sent back to the original site along with their login credentials. This means that people don't have to remember individual login information for each site they want to access, and the individual sites don't have access to people's passwords.

(In JHU terms, for example, a webpage hosted on www.cs.jhu.edu, the CS Department webserver, could request that a visitor log in using his or her JHED credentials. The CS webserver would direct the visitor's browser over to JHU's login servers, which would then approve the login and send the browser back to the original webpage. The CS-based webpage would then receive the JHED login information without actually having to know anything about the person's JHED password or details of the login. Shibboleth also allows CS webpages to permit logins with either CS ''or'' JHED credentials.)

This page describes how to use the Shibboleth resources available within the Computer Science department on your own webpages. For information about logging in to a site that uses Shibboleth, see [[Shibboleth]].

== Terminology ==

Shibboleth has a few terms that is uses for specific parts of the software. The central server that allows people to log in is called an ''Identity Provider'' or ''IdP''. The web server that wants to use those login credentials is called a ''Service Provider'' or ''SP''. Every IdP and SP is uniquely identified by its ''EntityID''. An EntityID looks like a URL (the main CS webserver's EntityID is <nowiki>https://www.cs.jhu.edu/shibboleth</nowiki>), but it doesn't have to actually go to a website.

Shibboleth only provides ''authentication'', which means that it provides a trusted source of account names. Shibboleth provides information that is equivalent to saying things like "the person at this browser has proven that they own the JHED ID that I will tell you about." It is up to you to configure your own ''authorization'' and determine which JHED IDs and CS accounts will be allowed to access your webpages.

== Shibboleth Servers Available in CS ==

Johns Hopkins operates an IdP that allows logins with [https://my.jh.edu/portal/web/help/what-is-jhed JHED IDs]. If you want to set up your own server to use the JHU IdP, you'll have to contact [http://www.it.johnshopkins.edu/services/directoryservices/jhea/Shibboleth/ the Enterprise Auth team], but our webserver (www.cs.jhu.edu) is already set up to use JHED IDs, so websites hosted there only need the configuration documented below.

The CS department runs an IdP for logins using CS Grad Net accounts. If you want to run your own web server that uses CS accounts, please contact [mailto:support@cs.jhu.edu support@cs.jhu.edu] for assistance. The CS department webserver (www.cs.jhu.edu) is already set up to use CS Grad Net accounts, so websites hosted there only need the configuration documented below.

The CS department's webserver (www.cs.jhu.edu) is configured as an SP for both JHED and CS Grad Net accounts.

== Account Information ==

Shibboleth provides a bit of information about the logged-in account, but the provided information differs between JHED and CS accounts. One thing that's the same for both is the username data, which is provided in the <tt>REMOTE_USER</tt> CGI environment variable.

If a person logs in via JHED, their <tt>REMOTE_USER</tt> username will be their JHED ID followed by "@johnshopkins.edu". Thus, a person with a JHED ID of "jdoe1" would be identified as "jdoe1@johnshopkins.edu".

If a person logs in via a CS Grad Net account, their <tt>REMOTE_USER</tt> username will be their CS Grad Net account name followed by "@cs.jhu.edu". Thus, a person with a CS Grad Net account name of "janedoe" would be identified as "janedoe@cs.jhu.edu".

== Session Length ==

Once someone logs into a CS-hosted webpage via Shibboleth, the CS webserver establishes a session to remember the login. So long as the session exists, the person will be able to continue accessing Shibboleth-protected pages without having to log in again.

Sessions are removed after one of two things occurs:

* Two hours pass without any activity from the logged-in person (i.e. the person didn't access any pages for two hours)
* Eight hours pass since the person's most recent login

== How to Use the www.cs.jhu.edu ''SP'' ==

You have two choices about how to use Shibboleth with your www.cs.jhu.edu webpages.

The first option is to put all of the authorization into a <tt>.htaccess</tt> file and let the www.cs.jhu.edu webserver manage everything. With this option, the webserver itself will determine who is allowed to see your pages. If you want to protect plain HTML files (i.e. you're not using [[Setting Up CGI Scripts on the CS Webservers|CGI]], [[Running PHP Scripts on the CS Webservers|PHP]] or something similar), this is the only option available to you. Even if you have dynamic content, your programs don't have to know anything about logins or authorization if you use this authorization approach.

The second option is to tell the www.cs.jhu.edu webserver that you want Shibboleth available but that your programs will decide what to do with the Shibboleth login information. This option can be more difficult to set up, but it gives you more flexibility in your treatment of the information you get from Shibboleth.

=== Option One: Webserver Authorization ===

Under <tt>public_html</tt>, you need to create a file named <tt>.htaccess</tt> ''in the top level directory'' where you want to restrict access. For example, if you wanted to require logins for any page under <nowiki>http://www.cs.jhu.edu/</nowiki>~''account''/secret, you would create the file as <tt>~/public_html/secret/.htaccess</tt>. Unless you simply want to give anyone with a JHED or CS account access, you'll also need to make a file named <tt>.htgroup</tt> that contains a group name and the accounts that should be members of that allowed group.

The <tt>.htaccess</tt> file should contain the following:

<pre>
# This activates Shibboleth
AuthType Shibboleth
ShibCompatWith24 On

# Shibboleth only works if the webpage is accessed via HTTPS (not HTTP). The
# following setting will redirect any clients from HTTP to HTTPS so that logins
# will always work. (If you don't use this and someone accesses the page via
# HTTP, they'll get a "No peer endpoint available to which to send SAML
# response" error message from the IdP.)
ShibRequestSetting redirectToSSL 443

# This requires everyone to log in before they can see the protected pages. If
# you don't have this line, people still won't be able to see the pages, but
# they won't be prompted to log in, so they'd have no way to get access.
ShibRequestSetting requireSession 1

# In order to access the pages, the person must be a member of the group named
# "allowed". You can use a different name for the group if you prefer; just
# make sure the group name matches what's in the .htgroup file.
Require group allowed

# This is the file that contains the definition of the "allowed" group. The
# path name must be fully qualified, so replace "<account>" with your account
# name. The file doesn't have to be under ~/public_html (and it's generally
# recommended that it go elsewhere) but putting it here simplifies the
# permissions necessary for the webserver to see it.
AuthGroupFile /users/<account>/public_html/secret/.htgroup

# This ensures that no one can see the contents of the group file.
<Files .htgroup>
Order Deny,Allow
Deny from all
</Files>
</pre>

Your <tt>.htgroup</tt> file contents will vary more depending on who you need to give access to. To continue the above example, if the people with ''JHED IDs'' '''jdoe1''' and '''fbar3''' should be given access as well as the person with ''CS account'' '''mumble''', put the following into <tt>~/public_html/secret/.htgroup</tt>:

<pre>
allowed: jdoe1@johnshopkins.edu fbar3@johnshopkins.edu mumble@cs.jhu.edu
</pre>

The format of the file is described in the Apache [http://httpd.apache.org/docs/2.2/mod/mod_authz_groupfile.html#authgroupfile AuthGroupFile] directive.

When you're done, set the [[File Permissions for Webpages|appropriate permissions on the files]] with the following command from the command line in the directory where you've saved them:

chmod 0604 .htaccess .htgroup

==== Using Only JHED IDs ====

By default, people logging into your site will be able to choose whether to use JHED or CS accounts. If you only want them to use JHED IDs, add this line anywhere in your <tt>.htaccess</tt> file:

<pre>
ShibRequestSetting entityID https://shibboleth.jh.edu/idp/shibboleth
</pre>

==== Using Only CS Accounts ====

By default, people logging into your site will be able to choose whether to use JHED or CS accounts. If you only want them to use CS Grad Net accounts, add this line anywhere in your <tt>.htaccess</tt> file:

<pre>
ShibRequestSetting entityID https://gidp.cs.jhu.edu/idp/shibboleth
</pre>

=== Option Two: Web Application Authorization ===

There is a lot more potential variation for this option, so only the most general information can be covered. If you need further assistance, please email [mailto:support@cs.jhu.edu support@cs.jhu.edu] with your questions.

At the very least, you will need a <tt>.htaccess</tt> file in the root directory of your web application. In it you will need at least the following directives:

<pre>
AuthType Shibboleth
ShibCompatWith24 On
Require Shibboleth
</pre>

Those will make Shibboleth information available to the application, but will not restrict access or even trigger Shibboleth authentication. (If you want to require Shibboleth authentication, add a line containing <tt>ShibRequestSetting requireSession 1</tt>.)

==== Custom Programming ====

If you're writing your own application, all you really need is to look at the contents of the <tt>REMOTE_USER</tt> environment variable to get the authenticated username (as [[#Account Information|described above]]). The particulars of how you grant access based on that username are up to you.

===== Logins =====

To trigger a login, direct the person on the website to the URL <tt><nowiki>https://www.cs.jhu.edu/Shibboleth.sso/Login</nowiki></tt>. (Obviously, if your page is already being accessed on <nowiki>https://www.cs.jhu.edu</nowiki> you don't need the protocol and hostname in your link.)

There are a few URL parameters you can use in conjunction with this. The <tt>target</tt> parameter gives the URL that the person should return to after logging in. If you don't use this, they'll be returned to the main https://www.cs.jhu.edu page, which is almost certainly not what you want.

The <tt>entityID</tt> parameter can be used to pick either JHED or CS as your authentication source (rather than allowing visitors to choose from between them, which is the default). Set <tt>entityID</tt> to <tt><nowiki>https://shibboleth.jh.edu/idp/shibboleth</nowiki></tt> for JHED IDs and <tt><nowiki>https://gidp.cs.jhu.edu/idp/shibboleth</nowiki></tt> for CS Grad Net accounts.

As an example, here's a link that would use only JHED IDs and would return people to <nowiki>https://www.cs.jhu.edu/~example/myapp</nowiki> after they've logged in:

<nowiki>https://www.cs.jhu.edu/Shibboleth.sso/Login?target=https://www.cs.jhu.edu/~example/myapp&entityID=https://shibboleth.jh.edu/idp/shibboleth</nowiki>

===== Logouts =====

We recommend that you '''''not use''' explicit logouts'' and instead just rely on the implicit length of sessions in the SP and IdP. The concept of "logging out of Shibboleth" is a surprisingly complicated one, for reasons sketched out on the [[Shibboleth#Logging Out|Shibboleth]] page (and detailed on the Shibboleth wiki's [https://wiki.shibboleth.net/confluence/display/SHIB2/SLOIssues Single Logout Issues] page).

If, despite the above, you really want to have a logout link in your webapp, you can link to <tt><nowiki>https://www.cs.jhu.edu/Shibboleth.sso/Logout</nowiki></tt>. That link takes at least one URL parameter: <tt>return</tt> gives a URL to which the person logging out may be sent after logout. As of March 2014, neither JHED nor CS uses that parameter, but it's useful to include it in case the Shibboleth implementations are changed in the future.

==== Integration with Other Applications ====

If you're using a third-party program, like [https://mediawiki.org MediaWiki] or [https://wordpress.org/ WordPress], you'll have to see if there are existing plugins or documentation for Shibboleth. You can also email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for assistance; the IT group has experience with Shibboleth integration for at least MediaWiki and DokuWiki.

[[Category:Webpages and Webservices]]

[[Category:Security]]

Using Shibboleth

2018-12-13T16:03:52Z

Phil.cs.jhu.edu: /* Using Only JHED IDs */

[http://shibboleth.net Shibboleth] is software that allows one website to use another website for login information, so that people who want to log in to a Shibboleth-based site are transparently redirected to a central login site to enter their account name and password and are then sent back to the original site along with their login credentials. This means that people don't have to remember individual login information for each site they want to access, and the individual sites don't have access to people's passwords.

(In JHU terms, for example, a webpage hosted on www.cs.jhu.edu, the CS Department webserver, could request that a visitor log in using his or her JHED credentials. The CS webserver would direct the visitor's browser over to JHU's login servers, which would then approve the login and send the browser back to the original webpage. The CS-based webpage would then receive the JHED login information without actually having to know anything about the person's JHED password or details of the login. Shibboleth also allows CS webpages to permit logins with either CS ''or'' JHED credentials.)

This page describes how to use the Shibboleth resources available within the Computer Science department on your own webpages. For information about logging in to a site that uses Shibboleth, see [[Shibboleth]].

== Terminology ==

Shibboleth has a few terms that is uses for specific parts of the software. The central server that allows people to log in is called an ''Identity Provider'' or ''IdP''. The web server that wants to use those login credentials is called a ''Service Provider'' or ''SP''. Every IdP and SP is uniquely identified by its ''EntityID''. An EntityID looks like a URL (the main CS webserver's EntityID is <nowiki>https://www.cs.jhu.edu/shibboleth</nowiki>), but it doesn't have to actually go to a website.

Shibboleth only provides ''authentication'', which means that it provides a trusted source of account names. Shibboleth provides information that is equivalent to saying things like "the person at this browser has proven that they own the JHED ID that I will tell you about." It is up to you to configure your own ''authorization'' and determine which JHED IDs and CS accounts will be allowed to access your webpages.

== Shibboleth Servers Available in CS ==

Johns Hopkins operates an IdP that allows logins with [https://my.jh.edu/portal/web/help/what-is-jhed JHED IDs]. If you want to set up your own server to use the JHU IdP, you'll have to contact [http://www.it.johnshopkins.edu/services/directoryservices/jhea/Shibboleth/ the Enterprise Auth team], but our webserver (www.cs.jhu.edu) is already set up to use JHED IDs, so websites hosted there only need the configuration documented below.

The CS department runs an IdP for logins using CS Grad Net accounts. If you want to run your own web server that uses CS accounts, please contact [mailto:support@cs.jhu.edu support@cs.jhu.edu] for assistance. The CS department webserver (www.cs.jhu.edu) is already set up to use CS Grad Net accounts, so websites hosted there only need the configuration documented below.

The CS department's webserver (www.cs.jhu.edu) is configured as an SP for both JHED and CS Grad Net accounts.

== Account Information ==

Shibboleth provides a bit of information about the logged-in account, but the provided information differs between JHED and CS accounts. One thing that's the same for both is the username data, which is provided in the <tt>REMOTE_USER</tt> CGI environment variable.

If a person logs in via JHED, their <tt>REMOTE_USER</tt> username will be their JHED ID followed by "@johnshopkins.edu". Thus, a person with a JHED ID of "jdoe1" would be identified as "jdoe1@johnshopkins.edu".

If a person logs in via a CS Grad Net account, their <tt>REMOTE_USER</tt> username will be their CS Grad Net account name followed by "@cs.jhu.edu". Thus, a person with a CS Grad Net account name of "janedoe" would be identified as "janedoe@cs.jhu.edu".

== Session Length ==

Once someone logs into a CS-hosted webpage via Shibboleth, the CS webserver establishes a session to remember the login. So long as the session exists, the person will be able to continue accessing Shibboleth-protected pages without having to log in again.

Sessions are removed after one of two things occurs:

* Two hours pass without any activity from the logged-in person (i.e. the person didn't access any pages for two hours)
* Eight hours pass since the person's most recent login

== How to Use the www.cs.jhu.edu ''SP'' ==

You have two choices about how to use Shibboleth with your www.cs.jhu.edu webpages.

The first option is to put all of the authorization into a <tt>.htaccess</tt> file and let the www.cs.jhu.edu webserver manage everything. With this option, the webserver itself will determine who is allowed to see your pages. If you want to protect plain HTML files (i.e. you're not using [[Setting Up CGI Scripts on the CS Webservers|CGI]], [[Running PHP Scripts on the CS Webservers|PHP]] or something similar), this is the only option available to you. Even if you have dynamic content, your programs don't have to know anything about logins or authorization if you use this authorization approach.

The second option is to tell the www.cs.jhu.edu webserver that you want Shibboleth available but that your programs will decide what to do with the Shibboleth login information. This option can be more difficult to set up, but it gives you more flexibility in your treatment of the information you get from Shibboleth.

=== Option One: Webserver Authorization ===

Under <tt>public_html</tt>, you need to create a file named <tt>.htaccess</tt> ''in the top level directory'' where you want to restrict access. For example, if you wanted to require logins for any page under <nowiki>http://www.cs.jhu.edu/</nowiki>~''account''/secret, you would create the file as <tt>~/public_html/secret/.htaccess</tt>. Unless you simply want to give anyone with a JHED or CS account access, you'll also need to make a file named <tt>.htgroup</tt> that contains a group name and the accounts that should be members of that allowed group.

The <tt>.htaccess</tt> file should contain the following:

<pre>
# This activates Shibboleth
AuthType Shibboleth
ShibCompatWith24 On

# Shibboleth only works if the webpage is accessed via HTTPS (not HTTP). The
# following setting will redirect any clients from HTTP to HTTPS so that logins
# will always work. (If you don't use this and someone accesses the page via
# HTTP, they'll get a "No peer endpoint available to which to send SAML
# response" error message from the IdP.)
ShibRequestSetting redirectToSSL 443

# This requires everyone to log in before they can see the protected pages. If
# you don't have this line, people still won't be able to see the pages, but
# they won't be prompted to log in, so they'd have no way to get access.
ShibRequestSetting requireSession 1

# In order to access the pages, the person must be a member of the group named
# "allowed". You can use a different name for the group if you prefer; just
# make sure the group name matches what's in the .htgroup file.
Require group allowed

# This is the file that contains the definition of the "allowed" group. The
# path name must be fully qualified, so replace "<account>" with your account
# name. The file doesn't have to be under ~/public_html (and it's generally
# recommended that it go elsewhere) but putting it here simplifies the
# permissions necessary for the webserver to see it.
AuthGroupFile /users/<account>/public_html/secret/.htgroup

# This ensures that no one can see the contents of the group file.
<Files .htgroup>
Order Deny,Allow
Deny from all
</Files>
</pre>

Your <tt>.htgroup</tt> file contents will vary more depending on who you need to give access to. To continue the above example, if the people with ''JHED IDs'' '''jdoe1''' and '''fbar3''' should be given access as well as the person with ''CS account'' '''mumble''', put the following into <tt>~/public_html/secret/.htgroup</tt>:

<pre>
allowed: jdoe1@johnshopkins.edu fbar3@johnshopkins.edu mumble@cs.jhu.edu
</pre>
[steve410@ugrad4 bin]$ ls -ld bash

The format of the file is described in the Apache [http://httpd.apache.org/docs/2.2/mod/mod_authz_groupfile.html#authgroupfile AuthGroupFile] directive.

When you're done, set the [[File Permissions for Webpages|appropriate permissions on the files]] with the following command from the command line in the directory where you've saved them:

chmod 0604 .htaccess .htgroup

==== Using Only JHED IDs ====

By default, people logging into your site will be able to choose whether to use JHED or CS accounts. If you only want them to use JHED IDs, add this line anywhere in your <tt>.htaccess</tt> file:

<pre>
ShibRequestSetting entityID https://shibboleth.jh.edu/idp/shibboleth
</pre>

==== Using Only CS Accounts ====

By default, people logging into your site will be able to choose whether to use JHED or CS accounts. If you only want them to use CS Grad Net accounts, add this line anywhere in your <tt>.htaccess</tt> file:

<pre>
ShibRequestSetting entityID https://gidp.cs.jhu.edu/idp/shibboleth
</pre>

=== Option Two: Web Application Authorization ===

There is a lot more potential variation for this option, so only the most general information can be covered. If you need further assistance, please email [mailto:support@cs.jhu.edu support@cs.jhu.edu] with your questions.

At the very least, you will need a <tt>.htaccess</tt> file in the root directory of your web application. In it you will need at least the following directives:

<pre>
AuthType Shibboleth
ShibCompatWith24 On
Require Shibboleth
</pre>

Those will make Shibboleth information available to the application, but will not restrict access or even trigger Shibboleth authentication. (If you want to require Shibboleth authentication, add a line containing <tt>ShibRequestSetting requireSession 1</tt>.)

==== Custom Programming ====

If you're writing your own application, all you really need is to look at the contents of the <tt>REMOTE_USER</tt> environment variable to get the authenticated username (as [[#Account Information|described above]]). The particulars of how you grant access based on that username are up to you.

===== Logins =====

To trigger a login, direct the person on the website to the URL <tt><nowiki>https://www.cs.jhu.edu/Shibboleth.sso/Login</nowiki></tt>. (Obviously, if your page is already being accessed on <nowiki>https://www.cs.jhu.edu</nowiki> you don't need the protocol and hostname in your link.)

There are a few URL parameters you can use in conjunction with this. The <tt>target</tt> parameter gives the URL that the person should return to after logging in. If you don't use this, they'll be returned to the main https://www.cs.jhu.edu page, which is almost certainly not what you want.

The <tt>entityID</tt> parameter can be used to pick either JHED or CS as your authentication source (rather than allowing visitors to choose from between them, which is the default). Set <tt>entityID</tt> to <tt><nowiki>https://shibboleth.jh.edu/idp/shibboleth</nowiki></tt> for JHED IDs and <tt><nowiki>https://gidp.cs.jhu.edu/idp/shibboleth</nowiki></tt> for CS Grad Net accounts.

As an example, here's a link that would use only JHED IDs and would return people to <nowiki>https://www.cs.jhu.edu/~example/myapp</nowiki> after they've logged in:

<nowiki>https://www.cs.jhu.edu/Shibboleth.sso/Login?target=https://www.cs.jhu.edu/~example/myapp&entityID=https://shibboleth.jh.edu/idp/shibboleth</nowiki>

===== Logouts =====

We recommend that you '''''not use''' explicit logouts'' and instead just rely on the implicit length of sessions in the SP and IdP. The concept of "logging out of Shibboleth" is a surprisingly complicated one, for reasons sketched out on the [[Shibboleth#Logging Out|Shibboleth]] page (and detailed on the Shibboleth wiki's [https://wiki.shibboleth.net/confluence/display/SHIB2/SLOIssues Single Logout Issues] page).

If, despite the above, you really want to have a logout link in your webapp, you can link to <tt><nowiki>https://www.cs.jhu.edu/Shibboleth.sso/Logout</nowiki></tt>. That link takes at least one URL parameter: <tt>return</tt> gives a URL to which the person logging out may be sent after logout. As of March 2014, neither JHED nor CS uses that parameter, but it's useful to include it in case the Shibboleth implementations are changed in the future.

==== Integration with Other Applications ====

If you're using a third-party program, like [https://mediawiki.org MediaWiki] or [https://wordpress.org/ WordPress], you'll have to see if there are existing plugins or documentation for Shibboleth. You can also email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for assistance; the IT group has experience with Shibboleth integration for at least MediaWiki and DokuWiki.

[[Category:Webpages and Webservices]]

[[Category:Security]]

CS Student Computing Lab Rules and Policies

2018-11-13T19:27:04Z

Phil.cs.jhu.edu: Redirected page to Computing Rules and Policies for CS I.T. Services and Computing Labs

#REDIRECT [[Computing Rules and Policies for CS I.T. Services and Computing Labs]]

Running PHP Scripts on the CS Webservers

2018-11-12T22:16:46Z

Phil.cs.jhu.edu:

The multi-user nature of the CS webservers require us to run PHP in a slightly uncommon way. We run PHP as a CGI using Apache's [https://httpd.apache.org/mod_fcgid/ mod_fcgid] [https://en.wikipedia.org/wiki/FastCGI FastCGI] module. That means that some common ways to use PHP need to be done slightly differently in our environment. These differences are documented below.

== Files in Your Home Directory ==

There is a <tt>'''php-cgi'''</tt> script in your <tt>~/public_html/cgi-bin</tt> directory. This is the script that runs the ''PHP CGI'' interpreter for you. Apache is told about this script by the <tt>'''FcgidWrapper'''</tt> directive in your <tt>'''~/public_html/.htaccess'''</tt> file.

''Changing either of these files should be done with care, as doing so could prevent PHP from working for your webpages.''

== Apache AddType Directives ==

The CS webservers treat any file that has a <tt>'''.php'''</tt> extension as a PHP script. In some cases, you might want files with other extensions to also be treated as PHP scripts.

Most documentation on the web describes how to use the [https://httpd.apache.org/docs/2.2/mod/mod_mime.html#AddType AddType] Apache directive in your <tt>'''.htaccess'''</tt> file for this, and that directive usually looks like this:

<pre class="bad">AddType application/x-httpd-php .html</pre>

''However,'' for our websites, ''instead of AddType,'' you will need to use the [https://httpd.apache.org/docs/2.2/mod/mod_mime.html#addhandler AddHandler] directive to process the file as a FastCGI script and give the ''full path'' to your <tt>'''php-cgi'''</tt> script to run it. For example, a ''grad'' account might use the following to execute HTML files at PHP scripts:

<pre class="good">AddHandler fcgid-script .html
FcgidWrapper /users/YOUR-ACCOUNT-HERE/public_html/cgi-bin/php-cgi .html</pre>

A ''ugrad'' account might use the following to execute files with a "<code>.p</code>" extension as PHP scripts:

<pre class="good">AddHandler fcgid-script .p
FcgidWrapper /home/YOUR-ACCOUNT-HERE/public_html/cgi-bin/php-cgi .p</pre>

== Apache ForceType Directives ==

Another way to force a particular file or files to be treated as PHP is to use a [https://httpd.apache.org/docs/2.2/mod/core.html#files <Files>] or [https://httpd.apache.org/docs/2.2/mod/core.html#directory <Directory>] section in your <tt>'''.htaccess'''</tt> file to target those files specifically. The customary documentation on the web uses the [https://httpd.apache.org/docs/2.2/mod/core.html#ForceType ForceType] directive for this:

<pre class="bad"><Files quux.foo>
ForceType application/x-httpd-php
</Files></pre>

''However,'' for our websites, ''instead of ForceType,'' you have to use the [https://httpd.apache.org/docs/2.0/mod/core.html#sethandler SetHandler] directive along with the ''full path'' to your <tt>'''php-cgi'''</tt> script. For a ''grad'' example:

<pre class="good"><Files quux.foo>
SetHandler fcgid-script
FcgidWrapper /users/YOUR-ACCOUNT-HERE/public_html/cgi-bin/php-cgi
</Files></pre>

''ugrad'' accounts, need to use a slightly different path:

<pre class="good"><Files quux.foo>
SetHandler fcgid-script
FcgidWrapper /home/YOUR-ACCOUNT-HERE/public_html/cgi-bin/php-cgi
</Files></pre>

== If PHP Doesn't Work ==

First, check to make sure your <tt>~/public_html/.htaccess</tt> and <tt>~/public_html/cgi-bin/php-cgi</tt> files exist and have the right contents and permissions.

For ''grad'' accounts, <tt>~/public_html/.htaccess</tt> should contain the following line:

FcgidWrapper /users/''your-account''/public_html/cgi-bin/php-cgi .php

For ''ugrad'' accounts, <tt>~/public_html/.htaccess</tt> should contain the following line:

FcgidWrapper /home/''your-account''/public_html/cgi-bin/php-cgi .php

'''Make sure you replace "''your-account''" with your actual account name.'''

<tt>~/public_html/cgi-bin/php-cgi</tt> should have the following contents:

#!/bin/sh
exec /usr/bin/php-cgi

[[File Permissions for Webpages|All of the files need to have specific permissions.]] Run the following commands from a terminal window to set their permissions appropriately:

chmod 0701 ~
chmod 0701 ~/public_html
chmod 0604 ~/public_html/.htaccess
chmod 0701 ~/public_html/cgi-bin
chmod 0700 ~/public_html/cgi-bin/php-cgi

If you are still having problems, please email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for assistance.

[[Category:Webpages_and_Webservices]]

Linux Clients on the CS Undergrad Net

2018-10-31T19:51:03Z

Phil.cs.jhu.edu:

The following is a list of Linux machines available for students, faculty, researchers, or staff. These Linux machines can be accessed remotely via <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 ''ugradx.cs.jhu.edu'', as it 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'''''

:* Accounts, mail, 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 '''ugrad24''' - standard ''Fedora 27'' Linux clients - split between both CS Undergraduate Labs (Malone 122 and G61). Each client has 8 cores (one 4-core i7 CPU with hyperthreading) and 16 GB RAM. Each system includes an NVIDIA-based GPU that's used with CUDA (installed) for coursework. ''These systems are also available remotely via ssh or scp.''

* '''ugradx''' - ''Fedora 27'' Linux-based compute server. 24 cores (two 64-bit 6-core CPUs with hyperthreading), 32gb RAM - ''only available remotely via ssh or scp''

* '''ugradz''' - ''Fedora 27'' Linux-based compute server. 8 core CPU, 32 GB RAM. ''Only available remotely via ssh or scp.''

'''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 Grad/Research Net

2018-10-31T19:50:39Z

Phil.cs.jhu.edu:

The following is a list of Linux machines available for grad students, faculty, researchers, or staff on the ''Grad/Research Net''. These Linux machines can be accessed remotely via <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 ''gradx.cs.jhu.edu'', as it 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 Grad/Research Net systems end with '''''.cs.jhu.edu''''' as in, '''''masters1.cs.jhu.edu'''''

* Accounts, mail, web, and home directories on the Grad Net machines ''are different than'' those on the [[Linux Clients on the CS Undergrad Net|Ugrad]] systems.

* 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]

* You are ''sharing these systems (CPU, memory, etc.) with other users,'' so 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.

* '''These Linux clients are primarily used for ''educational (coursework)'' purposes and for ''light research'' that does not impair CPU/memory resources for others.''' 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 Grad/Research Systems==

* '''masters1''' through '''masters16''' - ''Fedora 27'' Linux clients - Malone Hall G-61. Each client has 8 cores (one quad-core Xeon E3-1240 CPU with hyperthreading) and 16 GB RAM. Each system includes an NVIDIA-based GPU that's used with CUDA (installed) for coursework. ''These systems are also available remotely via ssh or scp.''

* '''gradx''' - ''Fedora 27'' Linux-based compute server. 24 cores (two 64-bit 6-core CPUs with hyperthreading), 32GB RAM - ''only available remotely via ssh or scp.''

* '''gradz''' - ''Fedora 27'' Linux-based compute server. 8 core, 32GB RAM - ''only available remotely via ssh or scp.''

'''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]]

MH 122 Projectors

2018-09-27T15:39:12Z

Phil.cs.jhu.edu:

The undergrad lab/collaboration room in Malone Hall room 122 has various projectors available for presentation use:

* A ''ceiling mounted projector'' in the main room is connected to the ''ugrad1'' lab machine and has video connectors on top of the ugrad1/ugrad2 table for use with laptops. The screen for the projector automatically comes down in the front of the room when the projector is activated.

* ''"Short-throw" projectors'' in each of the three small breakout rooms have connectors to be used with laptops. The wall closest to each breakout room projector acts as the screen.

The main room projector is controlled from the '''small Crestron control panel''' ''on the ugrad1/ugrad2 collaboration table''.

'''NOTE: When done using the projector for your session, ''please remember to shut down the projector''.'''

== Using the Main Projector With The ugrad1 Linux Lab Computer ==

There is a '''small ''Crestron'' control panel''' on the collaboration table next to '''''ugrad1's''''' monitor.

* Lower the projector screen.
** Press the down arrow on the screen control panel, which is on the wall below the clock.

* Activate the Crestron panel.
** If it's displaying the time and date with a dark background, touch the power icon on the right border of the display to turn it on.
** If it's displaying the time and date with a ''light'' background, touch the computer icon in the lower lefthand corner (right next to the home icon).
** If it's already shows "Present a Source", go the the next step.

* Touch the "Linux PC" button.

* '''IMPORTANT!''' When you're done with the projector, please press the power symbol button on the right border of the Crestron control panel to shut down the projector, then press the up arrow on the screen control panel to raise the screen.

=== Video Configuration ===

The ugrad1 lab machine ''defaults to a side-by-side configuration'' for the monitor and projector. You can move windows to the projector by dragging them off the left side of the monitor screen.

In some cases, it may be more convenient to have the projector function as a ''mirror'' of the monitor. To activate this with the default login environment (Mate Desktop):

:* Go to the ''"System"'' menu at the top of the screen.
:* Open the ''"Preferences"'' submenu.
:* Open the ''"Hardware"'' submenu.
:* Click on the ''"Displays"'' entry.
:* In the ''"Monitor Preferences"'' window that opens, check the checkbox labeled ''"Same image in all monitors"''.
:* Click the ''"Apply"'' button.
:* In the ''"Does the display look OK?"'' dialog box that comes up, click the "Keep This Configuration" button.

If you make changes to the monitor and projector layout, those changes will be remembered and reapplied every time you log into ugrad1.

=== Audio Configuration ===

The audio for ugrad1 can be directed through the room's speaker systems, but it is not set to do that by default. Here's how to set it up:

:* From the ''"Applications"'' menu, go to ''"Sound & Video"'' and start ''"PulseAudio Volume Control"''.
:* Go to the ''"Configuration"'' tab.
:* For the ''"GK106 HDMI Audio Controller"'' device, select the ''"Digital Stereo (HDMI 3) Output"'' profile. It should be the only one that is not ''"Unplugged"''.
:* To make all sounds go through the room's speakers:
:** Go to the ''"Output Devices"'' tab, find the '''HDMI''' controller and click its button with a checkmark in a green circle. (The tooltip for the button is ''"Set as fallback"''.
:* If you only want one program to use the room's speakers (e.g. a video playback program):
:** Start that program.
:** Go to the ''"Playback"'' tab in the '''PulseAudio Volume Control program''', find your program in the list and ''change its playback device to the HDMI output.''

 

== Using the Main Projector with a Laptop ==

* Lower the projector screen.
** Press the down arrow on the screen control panel, which is on the wall below the clock.

* Plug your laptop into the HDMI cable on top of the table closest to the printer.
** If you only have DisplayPort, DVI, or VGA connectors on your laptop, you'll need an adapter.

*There is a '''small Crestron''' control panel on the collaboration table next to the video input box.
** If it's displaying the time and date with a dark background, touch the power icon on the right border of the display to turn it on.
** If it's displaying the time and date with a ''light'' background, touch the computer icon in the lower lefthand corner (right next to the home icon).
** If it's already shows "Present a Source", go the the next step.

* Touch the "HDMI" button.

* At this point you may configure the projector as a second monitor on your laptop. It will probably appear as a monitor named ''"Crestron Electronics, Inc 36"''.

* '''IMPORTANT!''' When you're done with the projector, please press the power symbol button on the right border of the Crestron control panel to shut down the projector, then press the up arrow on the screen control panel to raise the screen.

 

== Using the Breakout Room Projectors ==

Each breakout room has VGA and HDMI connectors on the wall. There are also audio jacks to be used in conjunction with the VGA connectors.

* Connect your laptop to either the HDMI or VGA connector.
* Press the appropriate button on the input selection panel to the left of the connectors.

* '''IMPORTANT!''' When you're done, please press the '''"PWR OFF"''' button on the input selection panel to turn off the projector.

[[Category:Labs]]
[[Category:Audio-Visual]]

MH 122 Projector

2018-09-27T14:27:09Z

Phil.cs.jhu.edu: Redirected page to MH 122 Projectors

#REDIRECT: [[MH 122 Projectors]]

Using Shibboleth

2018-09-24T17:50:11Z

Phil.cs.jhu.edu:

[http://shibboleth.net Shibboleth] is software that allows one website to use another website for login information, so that people who want to log in to a Shibboleth-based site are transparently redirected to a central login site to enter their account name and password and are then sent back to the original site along with their login credentials. This means that people don't have to remember individual login information for each site they want to access, and the individual sites don't have access to people's passwords.

(In JHU terms, for example, a webpage hosted on www.cs.jhu.edu, the CS Department webserver, could request that a visitor log in using his or her JHED credentials. The CS webserver would direct the visitor's browser over to JHU's login servers, which would then approve the login and send the browser back to the original webpage. The CS-based webpage would then receive the JHED login information without actually having to know anything about the person's JHED password or details of the login. Shibboleth also allows CS webpages to permit logins with either CS ''or'' JHED credentials.)

This page describes how to use the Shibboleth resources available within the Computer Science department on your own webpages. For information about logging in to a site that uses Shibboleth, see [[Shibboleth]].

== Terminology ==

Shibboleth has a few terms that is uses for specific parts of the software. The central server that allows people to log in is called an ''Identity Provider'' or ''IdP''. The web server that wants to use those login credentials is called a ''Service Provider'' or ''SP''. Every IdP and SP is uniquely identified by its ''EntityID''. An EntityID looks like a URL (the main CS webserver's EntityID is <nowiki>https://www.cs.jhu.edu/shibboleth</nowiki>), but it doesn't have to actually go to a website.

Shibboleth only provides ''authentication'', which means that it provides a trusted source of account names. Shibboleth provides information that is equivalent to saying things like "the person at this browser has proven that they own the JHED ID that I will tell you about." It is up to you to configure your own ''authorization'' and determine which JHED IDs and CS accounts will be allowed to access your webpages.

== Shibboleth Servers Available in CS ==

Johns Hopkins operates an IdP that allows logins with [https://my.jh.edu/portal/web/help/what-is-jhed JHED IDs]. If you want to set up your own server to use the JHU IdP, you'll have to contact [http://www.it.johnshopkins.edu/services/directoryservices/jhea/Shibboleth/ the Enterprise Auth team], but our webserver (www.cs.jhu.edu) is already set up to use JHED IDs, so websites hosted there only need the configuration documented below.

The CS department runs an IdP for logins using CS Grad Net accounts. If you want to run your own web server that uses CS accounts, please contact [mailto:support@cs.jhu.edu support@cs.jhu.edu] for assistance. The CS department webserver (www.cs.jhu.edu) is already set up to use CS Grad Net accounts, so websites hosted there only need the configuration documented below.

The CS department's webserver (www.cs.jhu.edu) is configured as an SP for both JHED and CS Grad Net accounts.

== Account Information ==

Shibboleth provides a bit of information about the logged-in account, but the provided information differs between JHED and CS accounts. One thing that's the same for both is the username data, which is provided in the <tt>REMOTE_USER</tt> CGI environment variable.

If a person logs in via JHED, their <tt>REMOTE_USER</tt> username will be their JHED ID followed by "@johnshopkins.edu". Thus, a person with a JHED ID of "jdoe1" would be identified as "jdoe1@johnshopkins.edu".

If a person logs in via a CS Grad Net account, their <tt>REMOTE_USER</tt> username will be their CS Grad Net account name followed by "@cs.jhu.edu". Thus, a person with a CS Grad Net account name of "janedoe" would be identified as "janedoe@cs.jhu.edu".

== Session Length ==

Once someone logs into a CS-hosted webpage via Shibboleth, the CS webserver establishes a session to remember the login. So long as the session exists, the person will be able to continue accessing Shibboleth-protected pages without having to log in again.

Sessions are removed after one of two things occurs:

* Two hours pass without any activity from the logged-in person (i.e. the person didn't access any pages for two hours)
* Eight hours pass since the person's most recent login

== How to Use the www.cs.jhu.edu ''SP'' ==

You have two choices about how to use Shibboleth with your www.cs.jhu.edu webpages.

The first option is to put all of the authorization into a <tt>.htaccess</tt> file and let the www.cs.jhu.edu webserver manage everything. With this option, the webserver itself will determine who is allowed to see your pages. If you want to protect plain HTML files (i.e. you're not using [[Setting Up CGI Scripts on the CS Webservers|CGI]], [[Running PHP Scripts on the CS Webservers|PHP]] or something similar), this is the only option available to you. Even if you have dynamic content, your programs don't have to know anything about logins or authorization if you use this authorization approach.

The second option is to tell the www.cs.jhu.edu webserver that you want Shibboleth available but that your programs will decide what to do with the Shibboleth login information. This option can be more difficult to set up, but it gives you more flexibility in your treatment of the information you get from Shibboleth.

=== Option One: Webserver Authorization ===

Under <tt>public_html</tt>, you need to create a file named <tt>.htaccess</tt> ''in the top level directory'' where you want to restrict access. For example, if you wanted to require logins for any page under <nowiki>http://www.cs.jhu.edu/</nowiki>~''account''/secret, you would create the file as <tt>~/public_html/secret/.htaccess</tt>. Unless you simply want to give anyone with a JHED or CS account access, you'll also need to make a file named <tt>.htgroup</tt> that contains a group name and the accounts that should be members of that allowed group.

The <tt>.htaccess</tt> file should contain the following:

<pre>
# This activates Shibboleth
AuthType Shibboleth
ShibCompatWith24 On

# Shibboleth only works if the webpage is accessed via HTTPS (not HTTP). The
# following setting will redirect any clients from HTTP to HTTPS so that logins
# will always work. (If you don't use this and someone accesses the page via
# HTTP, they'll get a "No peer endpoint available to which to send SAML
# response" error message from the IdP.)
ShibRequestSetting redirectToSSL 443

# This requires everyone to log in before they can see the protected pages. If
# you don't have this line, people still won't be able to see the pages, but
# they won't be prompted to log in, so they'd have no way to get access.
ShibRequestSetting requireSession 1

# In order to access the pages, the person must be a member of the group named
# "allowed". You can use a different name for the group if you prefer; just
# make sure the group name matches what's in the .htgroup file.
Require group allowed

# This is the file that contains the definition of the "allowed" group. The
# path name must be fully qualified, so replace "<account>" with your account
# name. The file doesn't have to be under ~/public_html (and it's generally
# recommended that it go elsewhere) but putting it here simplifies the
# permissions necessary for the webserver to see it.
AuthGroupFile /users/<account>/public_html/secret/.htgroup

# This ensures that no one can see the contents of the group file.
<Files .htgroup>
Order Deny,Allow
Deny from all
</Files>
</pre>

Your <tt>.htgroup</tt> file contents will vary more depending on who you need to give access to. To continue the above example, if the people with ''JHED IDs'' '''jdoe1''' and '''fbar3''' should be given access as well as the person with ''CS account'' '''mumble''', put the following into <tt>~/public_html/secret/.htgroup</tt>:

<pre>
allowed: jdoe1@johnshopkins.edu fbar3@johnshopkins.edu mumble@cs.jhu.edu
</pre>
[steve410@ugrad4 bin]$ ls -ld bash

The format of the file is described in the Apache [http://httpd.apache.org/docs/2.2/mod/mod_authz_groupfile.html#authgroupfile AuthGroupFile] directive.

When you're done, set the [[File Permissions for Webpages|appropriate permissions on the files]] with the following command from the command line in the directory where you've saved them:

chmod 0604 .htaccess .htgroup

==== Using Only JHED IDs ====

By default, people logging into your site will be able to choose whether to use JHED or CS accounts. If you only want them to use JHED IDs, add this line anywhere in your <tt>.htaccess</tt> file:

<pre>
ShibRequestSetting entityID https://shibboleth.jh.edu/idp/shibboleth
</pre>[steve410@ugrad4 bin]$ ls -ld bash

==== Using Only CS Accounts ====

By default, people logging into your site will be able to choose whether to use JHED or CS accounts. If you only want them to use CS Grad Net accounts, add this line anywhere in your <tt>.htaccess</tt> file:

<pre>
ShibRequestSetting entityID https://gidp.cs.jhu.edu/idp/shibboleth
</pre>

=== Option Two: Web Application Authorization ===

There is a lot more potential variation for this option, so only the most general information can be covered. If you need further assistance, please email [mailto:support@cs.jhu.edu support@cs.jhu.edu] with your questions.

At the very least, you will need a <tt>.htaccess</tt> file in the root directory of your web application. In it you will need at least the following directives:

<pre>
AuthType Shibboleth
ShibCompatWith24 On
Require Shibboleth
</pre>

Those will make Shibboleth information available to the application, but will not restrict access or even trigger Shibboleth authentication. (If you want to require Shibboleth authentication, add a line containing <tt>ShibRequestSetting requireSession 1</tt>.)

==== Custom Programming ====

If you're writing your own application, all you really need is to look at the contents of the <tt>REMOTE_USER</tt> environment variable to get the authenticated username (as [[#Account Information|described above]]). The particulars of how you grant access based on that username are up to you.

===== Logins =====

To trigger a login, direct the person on the website to the URL <tt><nowiki>https://www.cs.jhu.edu/Shibboleth.sso/Login</nowiki></tt>. (Obviously, if your page is already being accessed on <nowiki>https://www.cs.jhu.edu</nowiki> you don't need the protocol and hostname in your link.)

There are a few URL parameters you can use in conjunction with this. The <tt>target</tt> parameter gives the URL that the person should return to after logging in. If you don't use this, they'll be returned to the main https://www.cs.jhu.edu page, which is almost certainly not what you want.

The <tt>entityID</tt> parameter can be used to pick either JHED or CS as your authentication source (rather than allowing visitors to choose from between them, which is the default). Set <tt>entityID</tt> to <tt><nowiki>https://shibboleth.jh.edu/idp/shibboleth</nowiki></tt> for JHED IDs and <tt><nowiki>https://gidp.cs.jhu.edu/idp/shibboleth</nowiki></tt> for CS Grad Net accounts.

As an example, here's a link that would use only JHED IDs and would return people to <nowiki>https://www.cs.jhu.edu/~example/myapp</nowiki> after they've logged in:

<nowiki>https://www.cs.jhu.edu/Shibboleth.sso/Login?target=https://www.cs.jhu.edu/~example/myapp&entityID=https://shibboleth.jh.edu/idp/shibboleth</nowiki>

===== Logouts =====

We recommend that you '''''not use''' explicit logouts'' and instead just rely on the implicit length of sessions in the SP and IdP. The concept of "logging out of Shibboleth" is a surprisingly complicated one, for reasons sketched out on the [[Shibboleth#Logging Out|Shibboleth]] page (and detailed on the Shibboleth wiki's [https://wiki.shibboleth.net/confluence/display/SHIB2/SLOIssues Single Logout Issues] page).

If, despite the above, you really want to have a logout link in your webapp, you can link to <tt><nowiki>https://www.cs.jhu.edu/Shibboleth.sso/Logout</nowiki></tt>. That link takes at least one URL parameter: <tt>return</tt> gives a URL to which the person logging out may be sent after logout. As of March 2014, neither JHED nor CS uses that parameter, but it's useful to include it in case the Shibboleth implementations are changed in the future.

==== Integration with Other Applications ====

If you're using a third-party program, like [https://mediawiki.org MediaWiki] or [https://wordpress.org/ WordPress], you'll have to see if there are existing plugins or documentation for Shibboleth. You can also email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for assistance; the IT group has experience with Shibboleth integration for at least MediaWiki and DokuWiki.

[[Category:Webpages and Webservices]]

[[Category:Security]]

Shells Available for CS Accounts (bash, tcsh, etc.)

2018-09-13T18:48:28Z

Phil.cs.jhu.edu: /* How to Change Your Shell */

In Linux (and other Unixes), the ''shell'' is the program that provides a command line for you to type in commands and programs to run. We have a number of shells available on our systems.

For accounts created before August 2018, the default shell was ''tcsh''. Since August 2018, the default shell has been ''bash''.

== Shells Available on CS Linux Clients ==

The following shells are available on the CS [[:Category:Linux Clients|Linux clients]]:

* bash
* tcsh
* zsh
* csh

== How to Tell What Shell You're Using ==

At a command line, run the following command:

echo $0

It will print the name of the shell you're currently using. In some circumstances, it might print a dash before the shell name. You can just ignore the dash.

== How to Change Your Shell ==

On a CS [[:Category:Linux Clients|Linux client]], run the following command:

chsh

When prompted for a new shell, you must type the full path to the shell.
* For grad net accounts, put "<code>/bin/</code>" in front of the shell name. (e.g. <code>/bin/bash</code>)
* For ugrad net accounts, put "<code>/usr/local/bin/</code>" in front of the shell name. (e.g. <code>/usr/local/bin/zsh</code>)
** It will take about fifteen minutes before all of our ugrad Linux clients see the change. If you log in to any of them immediately afterwards (before they've had time to get the update), you'll probably still be using your old shell.

== Setting Shell Variables ==

There are a number of environment variables that affect how your shell operates, especially <code>$PATH</code>, which tells the shell where to look for programs. The way to change shell variables differs between bourne family shells (e.g. bash) and c-shell family shells (e.g. tcsh).

Let's say we want to add the <code>~/bin</code> directory to the front of our <code>$PATH</code>.

In bash, that would be:

export PATH="~/bin:$PATH"

In tcsh, that would be:

setenv PATH "~/bin:$PATH"

== Shell Aliases ==

The syntax for aliases is only slightly different between bash and tcsh.

Let's say you have a <code>~/courses/cs220/assignments</code> directory that you access a lot. You can make a command to quickly go to that directory no matter where your are at the moment. Let's say you want to call the command "<code>cs220</code>".

In bash, you'd do this:

alias cs220='cd ~/courses/cs220/assignments/'

In tcsh, you'd do this:

alias cs220 'cd ~/courses/cs220/assignments/'

(Notice that there is no <code>=</code> in the tcsh example.)

== Configuration Files ==

If you want to save aliases or shell configurations to use every time you log in, you need to put them in a shell configuration file.

bash will use one of two files, depending on how it was started.

* If it was started directly after logging in to the system, bash will use <code>~/.bash_profile</code> .

* Otherwise, bash will use <code>~/.bashrc</code> .

We recommend putting the following line into <code>~/.bash_profile</code> and then using <code>~/.bashrc</code> for all of your configurations:

source ~/.bashrc

tcsh will use <code>~/.tcshrc</code> .

[[Category:Misc]]

Shells Available for CS Accounts (bash, tcsh, etc.)

2018-09-10T14:24:49Z

Phil.cs.jhu.edu:

In Linux (and other Unixes), the ''shell'' is the program that provides a command line for you to type in commands and programs to run. We have a number of shells available on our systems.

For accounts created before August 2018, the default shell was ''tcsh''. Since August 2018, the default shell has been ''bash''.

== Shells Available on CS Linux Clients ==

The following shells are available on the CS [[:Category:Linux Clients|Linux clients]]:

* bash
* tcsh
* zsh
* csh

== How to Tell What Shell You're Using ==

At a command line, run the following command:

echo $0

It will print the name of the shell you're currently using. In some circumstances, it might print a dash before the shell name. You can just ignore the dash.

== How to Change Your Shell ==

On a CS [[:Category:Linux Clients|Linux client]], run the following command:

chsh

When prompted for a new shell, you must type the full path to the shell. For grad net accounts, put "<code>/bin/</code>" in front of the shell name. (e.g. <code>/bin/bash</code>) For ugrad net accounts, put "<code>/usr/local/bin/</code>" in front of the shell name. (e.g. <code>/usr/local/bin/zsh</code>)

== Setting Shell Variables ==

There are a number of environment variables that affect how your shell operates, especially <code>$PATH</code>, which tells the shell where to look for programs. The way to change shell variables differs between bourne family shells (e.g. bash) and c-shell family shells (e.g. tcsh).

Let's say we want to add the <code>~/bin</code> directory to the front of our <code>$PATH</code>. In bash, that would be:

export PATH="~/bin:$PATH"

In tcsh, that would be:

setenv PATH "~/bin:$PATH"

== Shell Aliases ==

The syntax for aliases is only slightly different between bash and tcsh.

Let's say you have a <code>~/courses/cs220/assignments</code> directory that you access a lot. You can make a command to quickly go to that directory no matter where your are at the moment. Let's say the command should be "<code>cs220</code>".

In bash, you'd do this:

alias cs220='cd ~/courses/cs220/assignments/'

In tcsh, you'd do this:

alias cs220 'cd ~/courses/cs220/assignments/'

== Configuration Files ==

If you want to save aliases or shell configurations to use every time you log in, you need to put them in a shell configuration file.

bash will use one of two files, depending on how it was started. If it was started directly after logging in to the system, bash will use <code>~/.bash_profile</code> . Otherwise, bash will use <code>~/.bashrc</code> . We recommend putting the following line into <code>~/.bash_profile</code> and then using <code>~/.bashrc</code> for all of your configurations:

source ~/.bashrc

tcsh will use <code>~/.tcshrc</code> .

[[Category:Misc]]

Shells Available for CS Accounts (bash, tcsh, etc.)

2018-09-10T14:24:32Z

Phil.cs.jhu.edu: Created page with "In Linux (and other Unixes), the ''shell'' is the program that provides a command line for you to type in commands and programs to run. We have a number of shells available o..."

In Linux (and other Unixes), the ''shell'' is the program that provides a command line for you to type in commands and programs to run. We have a number of shells available on our systems.

For accounts created before August 2018, the default shell was ''tcsh''. Since August 2018, the default shell has been ''bash''.

== Shells Available on CS Linux Clients ==

The following shells are available on the CS [[:Category:Linux Clients|Linux clients]]:

* bash
* tcsh
* zsh
* csh

== How to Tell What Shell You're Using ==

At a command line, run the following command:

echo $0

It will print the name of the shell you're currently using. In some circumstances, it might print a dash before the shell name. You can just ignore the dash.

== How to Change Your Shell ==

On a CS [[:Category:Linux Clients|Linux client]], run the following command:

chsh

When prompted for a new shell, you must type the full path to the shell. For grad net accounts, put "<code>/bin/</code>" in front of the shell name. (e.g. <code>/bin/bash</code>) For ugrad net accounts, put "<code>/usr/local/bin/</code>" in front of the shell name. (e.g. <code>/usr/local/bin/zsh</code>)

== Setting Shell Variables ==

There are a number of environment variables that affect how your shell operates, especially <code>$PATH</code>, which tells the shell where to look for programs. The way to change shell variables differs between bourne family shells (e.g. bash) and c-shell family shells (e.g. tcsh).

Let's say we want to add the <code>~/bin</code> directory to the front of our <code>$PATH</code>. In bash, that would be:

export PATH="~/bin:$PATH"

In tcsh, that would be:

setenv PATH "~/bin:$PATH"

== Shell Aliases ==

The syntax for aliases is only slightly different between bash and tcsh.

Let's say you have a <code>~/courses/cs220/assignments</code> directory that you access a lot. You can make a command to quickly go to that directory no matter where your are at the moment. Let's say the command should be "<code>cs220</code>".

In bash, you'd do this:

alias cs220='cd ~/courses/cs220/assignments/'

In tcsh, you'd do this:

alias cs220 'cd ~/courses/cs220/assignments/'

== Configuration Files ==

If you want to save aliases or shell configurations to use every time you log in, you need to put them in a shell configuration file.

bash will use one of two files, depending on how it was started. If it was started directly after logging in to the system, bash will use <code>~/.bash_profile</code> . Otherwise, bash will use <code>~/.bashrc</code> . We recommend putting the following line into <code>~/.bash_profile</code> and then using <code>~/.bashrc</code> for all of your configurations:

source ~/.bashrc

tcsh will use <code>~/.tcshrc</code> .

Category:Accounts

2018-09-04T13:27:44Z

Phil.cs.jhu.edu: /* INTRO */

==INTRO==

The CS Department hosts both [[:Category:Linux_Clients|Linux login]] and [[:Category:MySQL|MySQL]] services for all CS-affiliated users. We also host [[Mapping_CS_Home_Directories_Using_SAMBA_(SMB) | SAMBA/SMB File Sharing services]] for CS faculty/staff/instructors/postdocs. Additionally, we have two Windows systems in the Ugrad Lab portion of G-61 available for general-use. (CS IT services mostly supports Linux-based systems.)

For all of these systems, you will need the appropriate user account. This category will provide you info on obtaining and maintaining CS-related accounts, account quotas (for Ugrad accounts), resetting your password, and other tips related to login, etc.

CS Linux accounts on our systems provide:

* A Linux shell and disk space for course work and light research.

* A CS-based [[:Category:Mail | email address]].

* Directory space to [[:Category:Webpages_and_Webservices | host a webpage]].

'''NOTES:'''

:* Although our [[:Category:Linux Clients | Grad and Ugrad Linux clients]] are similar, their account systems ''are not'', and require separate user accounts.

:* Our ''CS-related accounts'' '''are not''' associated with ''JHU's JHED accounts''. They are very different. Mind you, ''some'' CS Dept. webpages might require you to log in with your JHED account. '''(If you're having an issue with your ''JHED account'', please contact the JHU I.T. Helpdesk at 410-516-HELP.)'''

[[Obtaining CS Computer Accounts|Apply for a CS Linux account.]]

 

[[Category:All]]
[[Category:Computers Available on the CS Network]]
[[Category:Linux Clients]]

Mapping CS Home Directories Using SAMBA (SMB)

2018-08-15T14:48:15Z

Phil.cs.jhu.edu: /* How to Map Your CS Grad Net Home Linux Directory Using Samba */

== 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 available to anyone with a ''CS Grad Net Linux account''.

If your Grad Net Linux account was created before July 2018, you might need to follow our [[How To Reset Your Password|password reset procedure]] before you can use Samba. If you are unable to map your home directory using the below instructions, you will 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 [http://www.it.johnshopkins.edu/services/network/VPN JHU's VPN] service.

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

Typically, use the following mapping tools:

:'''''Windows:''' Windows Explorer -----> Tools -----> Map network drive''

:'''''MAC:''' Finder ----> Go ----> Connect to Server''

:'''''Linux:''' Varies depending on your desktop environment''

In every case, the server name 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)

2018-08-15T14:47:18Z

Phil.cs.jhu.edu:

== 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 available to anyone with a ''CS Grad Net Linux account''.

If your Grad Net Linux account was created before July 2018, you might need to follow our [[How To Reset Your Password|password reset procedure]] before you can use Samba. If you are unable to map your home directory using the below instructions, you will 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 [http://www.it.johnshopkins.edu/services/network/VPN JHU's VPN] service.

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

Typically, use the following mapping tools:

:'''''Windows:''' Windows Explorer -----> Tools -----> Map network drive''

:'''''MAC:''' Finder ----> Go ----> Connect to Server''

:'''''Linux:'' Varies depending on your desktop environment''

In every case, the server name 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]]

Changing Passwords On The CS Linux Systems

2018-08-15T14:31:24Z

Phil.cs.jhu.edu: /* Changing A Password On Our Grad/Research Net Linux Systems */

== Changing a Password on Our ''Grad/Research Net'' Linux Systems ==

Log into one of the [[Linux Clients on the CS Grad/Research Net|Linux systems on our Grad/Research Net]].

run the command:

passwd

You will twice be prompted for your current password and then your new password. The first time will change your Linux login password. The second time will change your [[Mapping CS Home Directories Using SAMBA (SMB)|Windows filesharing (Samba)]] password. Although you may use different passwords for each, we recommend using the same one both times.

You can begin using your new password immediately.

==Changing A Password On Our ''Ugrad Net'' Linux Systems==

Log into one of the [[Linux Clients on the CS Undergrad Net|Linux systems on our Ugrad Net]].

run the command:
passwd

You will see something like:

<pre>

Logging into hops to change your password...
Last login: Thu May 7 12:32:10 2015 from ugrad4.cs.jhu.edu
Welcome to hops.
1. Change your password.
2. Change your shell.
3. Exit.
Please enter a number ===>
Note that password changes can take up to 30 minutes to propogate to all ugrad machines.

</pre>

You should choose: ''1. Change your password.''

You will be prompted for your current password and then your new password.

There will be a delay of up to 30 minutes before your new password becomes available to our Ugrad Linux clients.

==Notes About Passwords On Our CS Linux (Grad or Ugrad) Systems==

* You can make them as long as you want.

* You can use whatever characters you'd like.

* Make it a password you can remember.

* Make your password complex enough to prevent someone from figuring it out. (You can Google ways to make a strong password.)

==If You Do Not Remember Your Current Password...==

You need your '''current''' password to change to a new password. If you do not recall what your '''current''' password is, please see: [[How To Reset Your Password]]

[[Category:Accounts]]

Programming Languages Available On The CS Linux Clients

2018-06-29T16:18:42Z

Phil.cs.jhu.edu: Change an external link to an internal one.

The following computer languages are installed on all of our [[:Category:Linux_Clients|CS Linux Clients]]:

* Shell scripting (using ''bash'', ''zsh'', and ''tcsh'')

* C (using ''gcc'' and ''clang'')

* C++ (using ''g++'' and ''clang++'')

* Java

* Perl

* Python (version 2.7 and version 3)

* Ruby

* PHP

* Fortran (using ''gfortran'')

* Go

* Scala

* Haskell

* Common Lisp (using ''clisp'', ''ecl'', ''gcl'', and sbcl)

* OCaml

* Node.js

[[Category:Software]]

Disk Quotas

2018-05-17T13:22:51Z

Phil.cs.jhu.edu:

On the '''''CS Ugrad Net''''', the Ugrad accounts may be 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.

'''NOTE:''' 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''.

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

Every account that is subject to a quota has a ''soft limit'' and a ''hard limit''. For most of our CS Ugrad accounts, those are ''8 GiB'' and ''8.5 GiB'', respectively. You cannot use more disk space than is given by your hard limit; once you hit that limit, all attempts to allocate more space (creating new files, making existing files larger, etc.) will fail.

If you exceed your soft limit, you will have a grace period of a week. During that period of time you may continue to create files and add to existing files as normal (as long as you don't hit your hard limit). If you remain above your soft limit for a full week, the soft limit begins to behave like a hard limit and you will be unable to use any additional space until you reduce your total disk usage below your soft limit.

''If you cannot allocate more space (you've hit your hard limit or you've exceeded your soft limit for more than a week), '''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.''

The CS Department has a notification system in place that will email ''your CS Ugrad account'' if you exceed your disk quota. This is a courtesy; you are ultimately responsible for keeping track of whether you're within the limits set for your account.

== 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:

Disk quotas for user ''account'' (uid ''12345''):
Filesystem space quota limit grace files quota limit grace
barley.cs.jhu.edu:/home
993776 4000000 4500000 9687 0 0

The numbers represent 1024-byte blocks. In the above example, the person is using 993776 blocks, which translates to roughly 970 MiB of data. The quota (aka soft limit) is 4000000 blocks, or just under 4 GiB. The hard limit is 4500000 blocks, or a little under 4.5 GiB.

== 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 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

This 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: 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 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.

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

In some cases, you might see a file with a name starting with "<code>.nfs</code>" followed by a long string of numbers. This happens when a file is deleted while a running program is still using it. Our systems simply rename the file while the program runs. As soon as the program exits, the <code>.nfs</code> file will be removed.

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, 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 <code>du</code> 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.

== 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]]
[[Category:Troubleshooting]]

Using IMAP on the Grad/Research Network

2018-05-07T14:59:38Z

Phil.cs.jhu.edu:

To ''receive'' CS e-mail using '''IMAP''', you must set your mail client to use '''''Secure IMAP'''''.

Configure the following settings on your mail client:

* '''Server Name:''' pop.cs.jhu.edu
* '''Port:''' 993
* '''Security Settings:''' SSL (Checking SSL will probably automatically set the correct port number of 993 for you, depending upon your e-mail client.)

Also, you'll want to set your inbox to be cleaned of mail you marked for deletion. Different email clients handle this function differently.

For example, under Thunderbird, select:

'''Clean up ("Expunge" Inbox on Exit.)'''

----
The above should allow you to receive mail from the server. You'll be prompted for your Grad/Research net password as needed.

You now create new mail folders as part of your IMAP environment. For example, under Thunderbird, use the '''Subscribe''' menu option.

'''''IMPORTANT:''' Please keep your inbox small. Remove e-mail that you no longer need, and file needed e-mails into mail folders.''

== Tell the IMAP Server Where Your Mail Folders are Located ==

'''Note''': This section applies mostly to older accounts with mailboxes in the account's home directory. People with newer accounts shouldn't need to do this, and for owners of older accounts we recommend [[Mail Folder Locations#Changing Your Grad Net Mailbox Location|changing your mailbox location]].

Depending upon what mail client you use, if you have mail folders (not referring to your inbox here) that you want access to, you need to set some kind of IMAP prefix path or root path. For example, Thunderbird calls it '''Mail Root Directory'''.

== Mac Users Who Have Issues with Server-reported "Empty/Blank IMAP Path Prefix" Messages Using Mail.app ==

'''Note''': This section applies mostly to older accounts with mailboxes in the account's home directory. People with newer accounts shouldn't need to worry about this problem, and for owners of older accounts we recommend [[Mail Folder Locations#Changing Your Grad Net Mailbox Location|changing your mailbox location]].

Generally, on your Mac, if you're using the standard Mail.app client, you set your '''IMAP Path Prefix''' to wherever your mail folders (not inbox) reside, and things work fine. However, if, while connecting to our IMAP server, you experience a message indicating Empty or Blank IMAP Path Prefix, you've then experienced a similar situation that another CS user has experienced. His solution follows:

:I think I found the solution. I created a mail directory and then moved all of the various mboxes into that directory. I set the imap path prefix to ~/mail and then told my client to use particular mailboxes for particular things (e.g., use the "Drafts" mailbox for drafts). Now, when I send a message, it doesn't tell me that the server is reporting that I should have an empty imap path prefix and offering to set it for me which is what it was previously doing.

In his case, the particular mboxes he put into his mail folder are:

* ''Apple Mail To Do''
* ''Deleted Messages''
* ''Drafts''
* ''Sent Messages''

[[category:Receiving Mail from the Grad/Research Network]]

Mail Folder Locations

2018-05-07T14:54:54Z

Phil.cs.jhu.edu: Created page with "If you only check your mail through IMAP or POP (as documented on our Receiving Email page), you don't need to worry about where the mail is actu..."

If you only check your mail through IMAP or POP (as documented on our [[:Category:Receiving Email|Receiving Email]] page), you don't need to worry about where the mail is actually stored. (With an exception for Grad Net accounts; see [[#Grad Net Mail Folders|that section below]] for details.) If you want to access the files directly (e.g. to set up procmail or use Pine directly on your mail folders), here's where they are.

== All Accounts: Two Types of Folders ==

When our server receives email for you, it places that email message in your '''''INBOX'''''. (Unless you [[Forwarding Mail|forward your mail]] or use procmail to put messages into a different folder.)

Your mail client will probably have the capability of moving emails into other folders, or '''''mailboxes'''''. Certain mailboxes often have special meaning for a particular client. For example, many clients store copies of email you've sent in a mailbox named "Sent".

The locations of your INBOX and your other mailboxes vary a little depending on whether you have a ugrad account or a grad net account.

== Ugrad Net Mail Folders ==

Your ''INBOX'' is a single file in <code>/var/spool/mail</code> (on any of our [[Linux Clients on the CS Undergrad Net|Linux clients]]) with a name matching your account name. If your account is "<code>example</code>", your INBOX is <code>/var/spool/mail/example</code>.

Your ''mailboxes'' are in the <code>Mail</code> directory in your home directory. Each mailbox is a separate file.

'''Note''': Some older accounts have their mailboxes in a directory named <code>mail</code> (starting with a lowercase "m"). At this point, however, most people will be using <code>Mail</code> (with an uppercase "M").

== Grad Net Mail Folders ==

Your ''INBOX'' is a single file in <code>/var/spool/mail</code> (on any of our [[Linux Clients on the CS Grad/Research Net|Linux clients]]) with a name matching your account name. If your account is "<code>example</code>", your INBOX is <code>/var/spool/mail/example</code>.

The location of your ''mailboxes'' is controlled by the contents of the <code>.mail_location</code> file in your home directory. If that file is empty or doesn't exist, your home directory is also the location of your mailboxes. Otherwise, the first line in that file gives the name of the directory containing your mailboxes. (Lines after the first line are currently ignored, but might be given other meanings in the future.)

Newer accounts have the <code>Mail</code> directory in the <code>.mail_location</code> file, so that's where those accounts' mailboxes are. Older accounts don't have a <code>.mail_location</code> file, so their mailboxes are in their home directory.

=== Changing Your Grad Net Mailbox Location ===

If you want to, you can change the location of your mailboxes for your grad net account. This can be particularly useful if you have an older account (with your mailboxes in your home directory) and you have a significant number of files in your home directory that are not mail folders. Many mail clients will try to treat every file in your mailbox directory (i.e. home directory) as a mail folder and will take a long time to look through all of them at times. (This can be mitigated a bit by [[Using IMAP on the Grad/Research Network#Tell the IMAP Server Where Your Mail Folders are Located|setting an IMAP prefix]], but changing your mailbox location is generally a better solution.)

# Decide where you want your mailboxes to be. We recommend <code>Mail</code> for consistency.
# If you have a mail client running, exit it.
# Create that directory, if it doesn't already exist.
# Move your current mailboxes into that directory.
# Move your <code>~/.subscriptions</code> file (if you have one) into that directory.
# Edit (or create) a <code>~/.mail_location</code> file and put your new mailbox directory into it on a single line.
# Restart your mail client and make sure everything looks right.

=== Switching from an IMAP Prefix to a Mailbox Subdirectory ===

Before our separate mailbox definitions were available, we recommended that people put all of their mailboxes into a subdirectory and then set that subdirectory as an [[Using IMAP on the Grad/Research Network#Tell the IMAP Server Where Your Mail Folders are Located|IMAP prefix]]. This setup works, but still has some drawbacks with respect to setting a <code>.mail_location</code> directly. To move from the old setup to the new one:

# If you have a mail client running, exit it.
# If you have some mail folders in your home directory (e.g. "Sent", "Junk"), move them into your mailbox directory.
#* If you're not sure whether you have any such folders, look at your <code>~/.subscriptions</code> file for any folders that aren't in the mailbox directory already.
# Move your <code>~/.subscriptions</code> file (if you have one) into your mailbox directory.
# Edit the <code>.subscriptions</.code> file and remove the mailbox directory prefix from your folders.
#* e.g. if your prefix is "<code>Mail</code>", you'd change things like "<code>Mail/seminars</code>" to just "<code>seminars</code>".
# Create a <code>~/.mail_location</code> file and put your mailbox directory into it on a single line.
# Restart your mail client, remove any IMAP prefix setting, and make sure everything looks right.

[[Category:Receiving Email]]

Using IMAP on the Grad/Research Network

2018-05-07T14:35:24Z

Phil.cs.jhu.edu:

To ''receive'' CS e-mail using '''IMAP''', you must set your mail client to use '''''Secure IMAP'''''.

Configure the following settings on your mail client:

* '''Server Name:''' pop.cs.jhu.edu
* '''Port:''' 993
* '''Security Settings:''' SSL (Checking SSL will probably automatically set the correct port number of 993 for you, depending upon your e-mail client.)

Also, you'll want to set your inbox to be cleaned of mail you marked for deletion. Different email clients handle this function differently.

For example, under Thunderbird, select:

'''Clean up ("Expunge" Inbox on Exit.)'''

----
The above should allow you to receive mail from the server. You'll be prompted for your Grad/Research net password as needed.

You now create new mail folders as part of your IMAP environment. For example, under Thunderbird, use the '''Subscribe''' menu option.

'''''IMPORTANT:''' Please keep your inbox small. Remove e-mail that you no longer need, and file needed e-mails into mail folders.''

== Tell the IMAP Server Where Your Mail Folders are Located ==

Depending upon what mail client you use, if you have mail folders (not referring to your inbox here) that you want access to, you need to set some kind of IMAP prefix path or root path. For example, Thunderbird calls it '''Mail Root Directory'''.

== Mac Users Who Have Issues with Server-reported "Empty/Blank IMAP Path Prefix" Messages Using Mail.app ==

Generally, on your Mac, if you're using the standard Mail.app client, you set your '''IMAP Path Prefix''' to wherever your mail folders (not inbox) reside, and things work fine. However, if, while connecting to our IMAP server, you experience a message indicating Empty or Blank IMAP Path Prefix, you've then experienced a similar situation that another CS user has experienced. His solution follows:

:I think I found the solution. I created a mail directory and then moved all of the various mboxes into that directory. I set the imap path prefix to ~/mail and then told my client to use particular mailboxes for particular things (e.g., use the "Drafts" mailbox for drafts). Now, when I send a message, it doesn't tell me that the server is reporting that I should have an empty imap path prefix and offering to set it for me which is what it was previously doing.

In his case, the particular mboxes he put into his mail folder are:

* ''Apple Mail To Do''
* ''Deleted Messages''
* ''Drafts''
* ''Sent Messages''

[[category:Receiving Mail from the Grad/Research Network]]

Category:Receiving Email

2018-05-07T13:56:23Z

Phil.cs.jhu.edu: /* OVERVIEW */

== OVERVIEW ==

There are several main protocols or methods of retrieving your CS dept. e-mail from your own computer.

''(Note that not all the mail clients listed below are located on our CS Linux and Windows machines.)''

* IMAP ([https://www.mozilla.org/en-US/thunderbird/ '''Thunderbird'''], [https://www.microsoft.com/en-us/outlook-com/ '''Outlook'''], [https://support.apple.com/mail '''Apple Mail'''], [http://projects.gnome.org/evolution '''Evolution'''])

* POP ([https://www.mozilla.org/en-US/thunderbird/ '''Thunderbird'''], [https://www.microsoft.com/en-us/outlook-com/ '''Outlook'''], [https://support.apple.com/mail '''Apple Mail'''], [http://projects.gnome.org/evolution '''Evolution'''])

* Mbox Format: Two mail clients are in use here ([http://www.washington.edu/pine '''Pine''']/[http://www.washington.edu/alpine '''Alpine'''] (they are the same program now), and [http://projects.gnome.org/evolution '''Evolution'''] -- A GUI-based email client, available while sitting in front of one of our [[:Category:Computers Available on the CS Network|CS Linux computers]]. You can run '''Evolution''', which is set to directly read your ''CS'' inbox, with no imap or pop configuration needed.

* Remotely: via ssh ([http://www.washington.edu/pine '''Pine''']/[http://www.washington.edu/alpine '''Alpine'''] -- they are the same program now]) -- ssh into one of our [[:Category:Computers Available on the CS Network|CS Linux clients]], and run '''pine'''

* Through our CS [[Webmail|Webmail service]], available for both our Grad/Research Net and ugrad Net users.

[[Category:Mail]]

Category:Mail

2018-05-07T13:54:11Z

Phil.cs.jhu.edu: /* NOTES: */

==INTRO==

The Computer Science Dept at JHU hosts '''''its own CS email service''''' (addresses of the form '''''@cs.jhu.edu'''''). This category provides documentation on various aspects of our CS email service.

===NOTES:===

:*Having a [[:Category:Accounts | CS Linux account]] provides you a CS email address.

:* For users who have '''both''' a CS Grad Linux account '''''and''''' a CS Ugrad Linux account, your email will '''default to your CS Grad account'''''.

:* JHU's Own Email System

:::'''JHU''' itself offers various types of its own email services as well, depending upon whether you're faculty, staff, students, etc. If you're interested in using '''JHU's mail services,''' visit [http://www.it.johnshopkins.edu/gettingstarted.html#EMAIL http://www.it.johnshopkins.edu/gettingstarted.html#EMAIL] which includes links to their various services including Outlook/Exchange and Outlook Web Access.

::: ''If you have issues with JHU's own email services, please contact the JHU Help Desk by phone at '''410-516-HELP'''''

:* Having both a CS and JHU Email Address

:::You can have a '''CS email address''' and a '''JHU email address''' at the same time. But, we recommend you forward whichever address you consider your secondary address to your primary address. (If your preferred email address is your own personal email address, you might want to forward your CS and/or JHU email addresses to that address instead.)

If you have questions/problems with CS's email service, and you've already looked through the [[:Category:Mail|Mail]] category of this website, please email [mailto:support@cs.jhu.edu support@cs.jhu.edu] with as much info as you can to help us answer your question or troubleshoot your email problem.

 

[[Category:All]]

Running VirtualBox On A CS Grad Or Ugrad Linux Client

2018-04-10T14:02:09Z

Phil.cs.jhu.edu:

==INTRO==

:You might take a class that requests that you run [https://www.virtualbox.org VirtualBox] on your own system. In case your system cannot run VirtualBox, our [[:Category:Linux_Clients|CS Linux clients]] provide VirtualBox capability as well.

=='''IMPORTANT''' NOTES ON USING ''VirtualBox'' ON OUR SYSTEMS==

* The easiest way to run VirtualBox on our systems is to run <code>virtualbox</code> from a command line).

* If you're ssh'ing into one of our systems, make sure you use X-forwarding or [[VNC]]. Otherwise your VirtualBox display will not show up on the system you're ssh'ing from.

* When you first launch VirtualBox on our systems, if you receive a pop-up that there is a new version of VirtualBox available, please ignore it (close the window.) We have a specific upgrade process for our Fedora systems, and any new software versions available to our systems will happen during that process.

* Remember, you are sharing our systems with other users, so please use the least amount of '''CPU''' & '''RAM''' as possible, to conserve resources.

* '''Disk Space:'''
** Another important resource to consider is '''disk space''' for your VirtualBox VM. Like CPU & RAM, please use the least amount of disk space as possible, since you share the same disks as students, faculty, instructors, and in some cases, researchers, postdocs, and staff.
** '''Ugrad users''' have [[Disk Quotas|disk quotas]], so, please make sure you can fit your VM into your allotted quota.

* And finally, if you need to create a more resource-hungry VM for class and do not need to use VirtualBox, please consider the [[:Category:Virtual Machines (VMs)|CS Department's general course-use VM Server]].

[[Category:Virtual Machines (VMs)]]

Forwarding Mail

2018-03-12T14:23:07Z

Phil.cs.jhu.edu: /* INTRO */

==INTRO==

When you receive a CS Linux account, you're also receiving an email address in the form of '''''yourusername''@cs.jhu.edu'''

You might choose to forward any email you receive at this CS address to some other preferred address. To do this, please follow the steps below.

==Setting Up Forwarding For Your CS Address==

* If you're a CS ''grad student, professor, researcher, postdoc or staff member,'' log into one of our [[Linux Clients on the CS Grad/Research Net]] and cd to your home directory.

:: or

* If you're a CS ''ugrad student,'' log into one of our [[Linux Clients on the CS Undergrad Net]] and cd to your home directory.

:: then...

* In the top level of your home directory, create a '''.forward''' file (don't forget the '''.''' ) using an editor.

* Put your preferred email account address as the only line in the <tt>.forward</tt> file.

* Save changes.

* Run the following command:

:: '''chmod 644 .forward'''

::(Again, don't forget the '''.''' in '''.forward''' )

Now, incoming mail to your CS address should be forwarded to your preferred address.

[[category:Mail]]

Accessing Linux Clients with SSH Public Key Authentication

2018-03-01T15:45:13Z

Phil.cs.jhu.edu:

All of our [[:Category:Linux Clients|Linux clients]] can be accessed via SSH. (See our [[SSH Key Fingerprints for Grad and Ugrad Net Linux Computers|SSH key fingerprint]] page to verify their host keys.) You can use your CS password to access the systems, but we also support public key authentication. (See [https://www.ssh.com/ssh/public-key-authentication SSH.com's public key authentication page] for an overview of what that does.)

Here is how to enable SSH public key authentication for your account:

== Generate Public and Private Keys ==

This will be done on your personal computer (desktop, laptop, etc.). The particulars will vary depending on what software you're using to connect to our systems; you should check your software's documentation.

That said, if you're running OpenSSH (as practically any Linux system is), you can probably generate a key pair with the following command:

ssh-keygen -t ed25519 -o -a 100

When prompted, enter a [https://theintercept.com/2015/03/26/passphrases-can-memorize-attackers-cant-guess/ good passphrase].

In any case, the key generation should leave you with two files, a ''public'' key and a ''private'' key. Keep the private key safe and don't share it with anyone. You'll use the public key in the next step.

== Authorize Your Key ==

Log into one of our [[:Category:Linux Clients|Linux clients]]. Create a <code>~/.ssh</code> directory, if you don't already have one, then edit your <code>~/.ssh/authorized_keys</code> file, creating it if necessary. The following commands will do that:

mkdir ~/.ssh
chmod 0700 ~/.ssh
nano ~/.ssh/authorized_keys

Copy the contents of your public key file and put them into the <code>~/.ssh/authorized_keys</code> file, '''all on one line'''. Each different key you authorize must be on one and only one line.

For example, a file that authorizes two keys might look like this (though the RSA key has been trimmed for readability):

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIL72YKEfA+1f8Uhh4Mg4CcJsRrBatvxrRHuD19v7m1z0 example@laptop
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDKMHeeIdCVYzb9z8HnTp+...7iEuEI08OPJboDsjFgtZ3O5Z+V+o1BepSJ3xHbdt example@desktop

Save the file.

Without logging out, try to SSH to one of our clients using your key. If it works, you're good. Otherwise you'll need to figure out what the problem is. As long as you know your password, though, you'll be able to get in even if the key doesn't work.

== Use Your Key ==

From this point, you should be able to use your private key to log in to our systems without being prompted for your password. How you tell your client to use the key will vary depending on the client.

If you're using OpenSSH and you didn't specify an alternate location for the key files when you generated them, everything should just work. If not, though, you can use SSH's <code>-i</code> parameter to explicitly tell it what key to use, e.g.:

ssh -i ~/.ssh/my-cs-key example@ugradx.cs.jhu.edu

== ssh-copy-id ==

OpenSSH comes with a utility to simplify the above process; it's called <code>ssh-copy-id</code>. After generating your key, you can run <code>ssh-copy-id</code> from your desktop/laptop in the same way that you'd use <code>ssh</code> to log in to a system, e.g.:

ssh-copy-id example@ugradz.cs.jhu.edu

After that finishes, you should log into the system yourself and verify that your <code>~/.ssh/authorized_keys</code> file only contains the keys you expect. Once that's done, you should be good to go.

[[Category:Linux Clients]]

Accessing Linux Clients with SSH Public Key Authentication

2018-03-01T15:44:05Z

Phil.cs.jhu.edu:

All of our [[:Category:Linux Clients|Linux clients]] can be accessed via SSH. (See our [[SSH Key Fingerprints for Grad and Ugrad Net Linux Computers|SSH key fingerprint]] page to verify their host keys.) You can use your CS password to access the systems, but we also support public key authentication. (See [https://www.ssh.com/ssh/public-key-authentication SSH.com's public key authentication page] for an overview of what that does.)

Here is how to enable SSH public key authentication for your account:

== Generate Public and Private Keys ==

This will be done on your personal computer (desktop, laptop, etc.). The particulars will vary depending on what software you're using to connect to our systems; you should check your software's documentation.

That said, if you're running OpenSSH (as practically any Linux system is), you can probably generate a key pair with the following command:

ssh-keygen -t ed25519 -o -a 100

When prompted, enter a [https://theintercept.com/2015/03/26/passphrases-can-memorize-attackers-cant-guess/ good passphrase].

In any case, the key generation should leave you with two files, a ''public'' key and a ''private'' key. Keep the private key safe and don't share it with anyone. You'll use the public key in the next step.

== Authorize Your Key ==

Log into one of our [[:Category:Linux Clients|Linux clients]]. Create a <code>~/.ssh</code> directory, if you don't already have one, then edit your <code>~/.ssh/authorized_keys</code> file, creating it if necessary. The following commands will do that:

mkdir ~/.ssh
chmod 0700 ~/.ssh
nano ~/.ssh/authorized_keys

Copy the contents of your public key file and put them into the <code>~/.ssh/authorized_keys</code> file, '''all on one line'''. Each different key you authorize must be on one and only one line.

For example, a file that authorizes two keys might look like this:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIL72YKEfA+1f8Uhh4Mg4CcJsRrBatvxrRHuD19v7m1z0 example@laptop
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDKMHeeIdCVYzb9z8HnTp+c+sttMHekF1+uBxT/E1SfXKitQLthdLXIz/9eiN3VX2zDGSk7azHpGhOxDR/dIuNJ3u8nLi4tSdbxhu7lWMLU7lrCgD5L3WRNQ62mFq1meMixdTzkryYyGLgKjQGRziCSNZIrvEJHdGAhZSyd+jvskBL7HKhLF15YYPTjbRoTi2sdww0g5BU9ZbH7xUoRYvUrepxYcSGgtHuoy125nVTuOYt/WFRM4AJpT/XmE8VGdp+4fjN9kd2JFiF3rkM3ayLOL2Xe1yK+BQ5u4OGZUU5GL5yu7iEuEI08OPJboDsjFgtZ3O5Z+V+o1BepSJ3xHbdt example@desktop

Save the file.

Without logging out, try to SSH to one of our clients using your key. If it works, you're good. Otherwise you'll need to figure out what the problem is. As long as you know your password, though, you'll be able to get in even if the key doesn't work.

== Use Your Key ==

From this point, you should be able to use your private key to log in to our systems without being prompted for your password. How you tell your client to use the key will vary depending on the client.

If you're using OpenSSH and you didn't specify an alternate location for the key files when you generated them, everything should just work. If not, though, you can use SSH's <code>-i</code> parameter to explicitly tell it what key to use, e.g.:

ssh -i ~/.ssh/my-cs-key example@ugradx.cs.jhu.edu

== ssh-copy-id ==

OpenSSH comes with a utility to simplify the above process; it's called <code>ssh-copy-id</code>. After generating your key, you can run <code>ssh-copy-id</code> from your desktop/laptop in the same way that you'd use <code>ssh</code> to log in to a system, e.g.:

ssh-copy-id example@ugradz.cs.jhu.edu

After that finishes, you should log into the system yourself and verify that your <code>~/.ssh/authorized_keys</code> file only contains the keys you expect. Once that's done, you should be good to go.

[[Category:Linux Clients]]

Accessing Linux Clients with SSH Public Key Authentication

2018-03-01T15:40:59Z

Phil.cs.jhu.edu: Created page with "All of our Linux clients can be accessed via SSH. (See our SSH key fingerprint page..."

All of our [[:Category:Linux Clients|Linux clients]] can be accessed via SSH. (See our [[SSH Key Fingerprints for Grad and Ugrad Net Linux Computers|SSH key fingerprint]] page to verify their host keys.) You can use your CS password to access the systems, but we also support public key authentication. (See [https://www.ssh.com/ssh/public-key-authentication SSH.com's public key authentication page] for an overview of what that does.)

Here is how to enable SSH public key authentication for your account:

== Generate Public and Private Keys ==

This will be done on your personal computer (desktop, laptop, etc.). The particulars will vary depending on what software you're using to connect to our systems; you should check your software's documentation.

That said, if you're running OpenSSH (as practically any Linux system is), you can probably generate a key pair with the following command:

ssh-keygen -t ed25519 -o -a 100

When prompted, enter a [https://theintercept.com/2015/03/26/passphrases-can-memorize-attackers-cant-guess/ good passphrase].

In any case, the key generation should leave you with two files, a ''public'' key and a ''private'' key. Keep the private key safe and don't share it with anyone. You'll use the public key in the next step.

== Authorize Your Key ==

Log into one of our [[:Category:Linux Clients|Linus clients]]. Create a <code>~/.ssh</code> directory, if you don't already have one, then edit your <code>~/.ssh/authorized_keys</code> file, creating it if necessary. The following commands will do that:

mkdir ~/.ssh
chmod 0700 ~/.ssh
nano ~/.ssh/authorized_keys

Copy the contents of your public key file and put them into the <code>~/.ssh/authorized_keys</code> file, '''all on one line'''. Each different key you authorize must be on one and only one line.

For example, a file that authorizes two keys might look like this:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIL72YKEfA+1f8Uhh4Mg4CcJsRrBatvxrRHuD19v7m1z0 example@laptop
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDKMHeeIdCVYzb9z8HnTp+c+sttMHekF1+uBxT/E1SfXKitQLthdLXIz/9eiN3VX2zDGSk7azHpGhOxDR/dIuNJ3u8nLi4tSdbxhu7lWMLU7lrCgD5L3WRNQ62mFq1meMixdTzkryYyGLgKjQGRziCSNZIrvEJHdGAhZSyd+jvskBL7HKhLF15YYPTjbRoTi2sdww0g5BU9ZbH7xUoRYvUrepxYcSGgtHuoy125nVTuOYt/WFRM4AJpT/XmE8VGdp+4fjN9kd2JFiF3rkM3ayLOL2Xe1yK+BQ5u4OGZUU5GL5yu7iEuEI08OPJboDsjFgtZ3O5Z+V+o1BepSJ3xHbdt example@desktop

Save the file.

Without logging out, try to SSH to one of our clients using your key. If it works, you're good. Otherwise you'll need to figure out what the problem is. As long as you know your password, though, you'll be able to get in even if the key doesn't work.

== Use Your Key ==

From this point, you should be able to use your private key to log in to our systems without being prompted for your password. How you tell your client to use the key will vary depending on the client.

If you're using OpenSSH and you didn't specify an alternate location for the key files when you generated them, everything should just work. If not, though, you can use SSH's <code>-i</code> parameter to explicitly tell it what key to use, e.g.:

ssh -i ~/.ssh/my-cs-key example@ugradx.cs.jhu.edu

== ssh-copy-id ==

OpenSSH comes with a utility to simplify the above process; it's called <code>ssh-copy-id</code>. After generating your key, you can run <code>ssh-copy-id</code> from your desktop/laptop in the same way that you'd use <code>ssh</code> to log in to a system, e.g.:

ssh-copy-id example@ugradz.cs.jhu.edu

After that finishes, you should log into the system yourself and verify that your <code>~/.ssh/authorized_keys</code> file only contains the keys you expect. Once that's done, you should be good to go.

[[Category:Linux Clients]]

Notices

2018-01-23T12:51:07Z

Phil.cs.jhu.edu: /* OUTAGE #1 - Major CS UGrad Net service outage (mail, web, home directories, login, etc.) */

== SERVICE OUTAGES ==



=== UNPLANNED CS SERVICE OUTAGES ===

:None at this time.

=== PLANNED CS SERVICE OUTAGES ===


::::'''''NOTE: DATE CHANGE BELOW for OUTAGE #1!!!!!!!!'''''

====OUTAGE #1 - Major CS ''UGrad Net'' service outage (mail, web, home directories, login, etc.) ====

'''Update 2''': As of 7:45 am, all services are available.

'''Update''': As of 7:00 am, all services are available ''except for ugradx''. It will need some additional time to finish its updates.

'''WHAT:''' Major CS Ugrad Net IT services outage, as we apply security updates to our systems.

'''WHEN:''' '''''Rescheduled for''''' Tuesday, January, 23, from 5am to approx 7am.

'''DETAILS:''' Many of our CS Ugrad Net servers will be shut down to apply security updates. We will apply these updates on Tuesday, January 23, from 5am to approximately 7am.

During the process of applying updates, several of our CS services will be unavailable. If there are any unexpected complications during the update process that will delay the restoration of services, we will update the CS IT Support Wiki's Notices page at https://support.cs.jhu.edu/wiki/Notices

Suspended (Unavailable) Ugrad Net services while the servers are updated:

* CS Ugrad Mail service, both incoming and outgoing, will be suspended for CS Ugrad Net users.

* Incoming mail should be queued by the sender until our mail service is back up again. Outgoing mail will not be available.

* IMAP, POP, and Webmail from our CS (Ugrad Net) Mail server will be unavailable.

* CS Ugrad Net webpages will be unavailable.

* CS Ugrad Net user accounts/home directories will be inaccessible during the downtime.

* ssh service to our CS Ugrad Net Linux boxes (ugrad1 through ugrad24, ugradx, and ugradz) will be unavailable.

* Console (desktop) access to ugrad1 through ugrad24 will be unavailable.

* MySQL service via the dbase.cs.jhu.edu server (Dr. Yarowsky's class) will be unavailable.

Updates, if necessary, will be posted here.

 

====OUTAGE #2 - ''gradx'' & ''ugradx'' compute servers unavailable the morning of Thursday, January 25.====

'''WHAT:''' ''gradx'' & ''ugradx'' compute servers will be unavailable the morning of Thursday, January 25 due to an upgrade to Fedora 27 and patch installations.

'''WHEN:''' Thursday, January 25, from 8:30am until 1pm.

'''DETAILS:''' Two of CS's remotely-accessible (through ssh) compute servers, ''gradx'' of the CS Grad Net and ''ugradx'' of the CS Ugrad Net, will be shut down so that they can be upgraded to Fedora 27 and for patch installations. During the time they are down, you may still access our other two compute servers ''gradz'' and ''ugradz'' or any one of our other [https://support.cs.jhu.edu/wiki/Category:Linux_Clients CS Linux Clients]

 

====OUTAGE #3 - ''gradz'' & ''ugradz'' compute servers unavailable the morning of Friday, January 26. ====

'''WHAT:''' ''gradz'' & ''ugradz'' compute servers will be unavailable the morning of Friday, January 26 due to an upgrade to Fedora 27 and patch installations.

'''WHEN:''' Friday, January 26, from 8:30am until 1pm.

'''DETAILS:''' Two of CS's remotely-accessible (through ssh) compute servers, ''gradz'' of the CS Grad Net and ''ugradz'' of the CS Ugrad Net, will be shut down so that they can be upgraded to Fedora 27 and for patch installations. During the time they are down, you may still access our other two compute servers ''gradx'' and ''ugradx'' or any one of our other [https://support.cs.jhu.edu/wiki/Category:Linux_Clients CS Linux Clients]











== CS COMPUTING LAB AVAILABILITY ==

=== MH 122 (Ugrad Lab) ===

====Projector in the main MH 122 Ugrad lab is down.====

: 11/2/17 - Kit-cats (JHU's A/V group) has been called. They have been out and are evaluating their options for repair. ETA for repair is unknown at this time.



=== MH G-61 (Masters/Ugrad Lab)===

:None at this time.










[[Category:All]]

Notices

2018-01-23T12:12:40Z

Phil.cs.jhu.edu: /* OUTAGE #1 - Major CS UGrad Net service outage (mail, web, home directories, login, etc.) */

== SERVICE OUTAGES ==



=== UNPLANNED CS SERVICE OUTAGES ===

:None at this time.

=== PLANNED CS SERVICE OUTAGES ===


::::'''''NOTE: DATE CHANGE BELOW for OUTAGE #1!!!!!!!!'''''

====OUTAGE #1 - Major CS ''UGrad Net'' service outage (mail, web, home directories, login, etc.) ====

'''Update''': as of 7:00 am, all services are available ''except for ugradx''. It will need some additional time to finish its updates.

'''WHAT:''' Major CS Ugrad Net IT services outage, as we apply security updates to our systems.

'''WHEN:''' '''''Rescheduled for''''' Tuesday, January, 23, from 5am to approx 7am.

'''DETAILS:''' Many of our CS Ugrad Net servers will be shut down to apply security updates. We will apply these updates on Tuesday, January 23, from 5am to approximately 7am.

During the process of applying updates, several of our CS services will be unavailable. If there are any unexpected complications during the update process that will delay the restoration of services, we will update the CS IT Support Wiki's Notices page at https://support.cs.jhu.edu/wiki/Notices

Suspended (Unavailable) Ugrad Net services while the servers are updated:

* CS Ugrad Mail service, both incoming and outgoing, will be suspended for CS Ugrad Net users.

* Incoming mail should be queued by the sender until our mail service is back up again. Outgoing mail will not be available.

* IMAP, POP, and Webmail from our CS (Ugrad Net) Mail server will be unavailable.

* CS Ugrad Net webpages will be unavailable.

* CS Ugrad Net user accounts/home directories will be inaccessible during the downtime.

* ssh service to our CS Ugrad Net Linux boxes (ugrad1 through ugrad24, ugradx, and ugradz) will be unavailable.

* Console (desktop) access to ugrad1 through ugrad24 will be unavailable.

* MySQL service via the dbase.cs.jhu.edu server (Dr. Yarowsky's class) will be unavailable.

Updates, if necessary, will be posted here.

 

====OUTAGE #2 - ''gradx'' & ''ugradx'' compute servers unavailable the morning of Thursday, January 25.====

'''WHAT:''' ''gradx'' & ''ugradx'' compute servers will be unavailable the morning of Thursday, January 25 due to an upgrade to Fedora 27 and patch installations.

'''WHEN:''' Thursday, January 25, from 8:30am until 1pm.

'''DETAILS:''' Two of CS's remotely-accessible (through ssh) compute servers, ''gradx'' of the CS Grad Net and ''ugradx'' of the CS Ugrad Net, will be shut down so that they can be upgraded to Fedora 27 and for patch installations. During the time they are down, you may still access our other two compute servers ''gradz'' and ''ugradz'' or any one of our other [https://support.cs.jhu.edu/wiki/Category:Linux_Clients CS Linux Clients]

 

====OUTAGE #3 - ''gradz'' & ''ugradz'' compute servers unavailable the morning of Friday, January 26. ====

'''WHAT:''' ''gradz'' & ''ugradz'' compute servers will be unavailable the morning of Friday, January 26 due to an upgrade to Fedora 27 and patch installations.

'''WHEN:''' Friday, January 26, from 8:30am until 1pm.

'''DETAILS:''' Two of CS's remotely-accessible (through ssh) compute servers, ''gradz'' of the CS Grad Net and ''ugradz'' of the CS Ugrad Net, will be shut down so that they can be upgraded to Fedora 27 and for patch installations. During the time they are down, you may still access our other two compute servers ''gradx'' and ''ugradx'' or any one of our other [https://support.cs.jhu.edu/wiki/Category:Linux_Clients CS Linux Clients]











== CS COMPUTING LAB AVAILABILITY ==

=== MH 122 (Ugrad Lab) ===

====Projector in the main MH 122 Ugrad lab is down.====

: 11/2/17 - Kit-cats (JHU's A/V group) has been called. They have been out and are evaluating their options for repair. ETA for repair is unknown at this time.



=== MH G-61 (Masters/Ugrad Lab)===

:None at this time.










[[Category:All]]

CUDA On The CS Linux Clients

2018-01-02T13:21:10Z

Phil.cs.jhu.edu:

==CUDA On The CS Linux Clients==

:[https://developer.nvidia.com/cuda-zone '''CUDA'''] is a parallel computing platform and application programming interface (API) model created by Nvidia.

:It will only run on our [[GPUs In The CS Linux Clients|CS Linux clients that include GPUs]].

:Although the CS IT Support Group makes the CUDA software available on our GPU-enabled systems, we do not use CUDA ourselves. We therefore do not have the experience necessary to provide instructions on how to use the CUDA toolchain and libraries.

:The CUDA tools should work as their standard documentation say they do. If for some reason they do not, please email [mailto:support@cs.jhu.edu support@cs.jhu.edu] and let us know as much information as possible, and we'll see if we can help correct the issue with our installation.

:To learn how to use CUDA, we recommend consulting its online documentation or discussing its use with your instructor.

[[Category:Software]]

Preventing Your Programs From Overrunning Our Computers

2017-12-04T15:26:14Z

Phil.cs.jhu.edu:

== Introduction ==

:As part of being a Computer Science student, you will no doubt create and run your own programs on our [[:Category:Linux_Clients|CS Linux Systems]]. You also might be downloading programs from elsewhere and running then on our systems as well.

:It's possible that software you write (or software you've downloaded and run) could, when running, exceed the existing resources on our systems.

== Computing System Resources that Could Be Exceeded ==

* Memory (RAM)

* CPU (processing power)

* Disk space
** ''Ugrad Net'' users have a [[Disk Quotas|disk quota]] to prevent that.
** ''Grad/Research Net'' users do not have specific disk quotas but must realize that they share their disk space with faculty, staff, etc. So, they must pay close attention to the disk space they use.
** Disk space not only included your home directory, but can also include your use of the Linux systems's '''/tmp''' directory as well.

==Typical Symptoms of Exceeding Computer Resources on Our Linux Systems==

* Timeouts ssh'ing into the computer.

* Programs run ''much'' slower than usual

* Programs stop running because they run out of RAM or swap disk space.

==Who Is Affected When Your Program Uses Up Resources on One of Our Linux Systems?==

:Because all our our CS Linux computers are '''multiuser''' systems, programs that exceed the computer's resources, slowing down the system, could potentially affect '''''all''''' the users logged into those systems, remotely, or at the actual computer console.

:Exceeding the computer's resources could also affect programs running in the background, perhaps as part of the computer's own system software or other users' batch jobs.

:'''''So... always be aware that you are not necessarily the only one logged into a system when you're running your own programs.'''''

==Tips to Prevent Your Programs from Exceeding the System Resources on Our Computers==

* Try to design your programs and/or datasets so that their running memory requirements don't exceed the capabilities of the system they're running on. Therefore, become familiar with the specs of our CS Linux systems:
** [[Linux_Clients_on_the_CS_Grad/Research_Net|Specs on our Grad/Research Net Linux Computers]]
** [[Linux_Clients_on_the_CS_Undergrad_Net|Specs on our Ugrad Net Linux Computers]]

* Try to avoid using the system's complete RAM memory as much as possible. Put safeguards into your programs to monitor your use of memory.

* Try to run your programs during low-demand times of day (mornings are best; late evenings are the most busy.)

* Try not to tie up the computer's resources for longer than the program needs to run.

:: '''Do not forget that you are running programs.''' One of the biggest areas we've had issues with is that some users start their programs in the background and forget that the programs are still running. And in some cases, the programs have issues and start using more resources than actually needed.

::'''Therefore... ''please make sure you check in on your running programs often, and use monitoring tools to make sure you are not exceeding resources.'''''

==Monitoring Your Processes' Memory and CPU Usage with Linux Commands==
:Use the '''top''' or '''htop''' programs to see your program's stats.
:* '''top'''
:** top -u ''username''
:* '''htop'''
:** htop -u ''username''
:** htop --user=''username''
:* '''ps'''
:** ps -u ''username''

==Ending or Modifying Your Running Process Using Linux Commands==

===Ending a Process===

:* '''kill''' - Send a signal to a process, usually to stop the process from running (which is why it's named "kill")
:** First, determine process ID (PID)
:** Start by sending the HUP [https://www.tecmint.com/how-to-kill-a-process-in-linux signal]
:*** Example: Kill process with PID 15476 using signal HUP:
:**** <code>kill -HUP 15476</code>
:** If the process is still running, use the TERM signal. (This is the default signal if one is not specified.)
:*** e.g.: <code>kill -TERM ''15476''</code>
:** If the process is ''still'' running, use the KILL signal. This forces the process to exit, without allowing it to clean up after itself, so it's recommended only of the other two signals don't have an effect. (Some online references refer to "<code>kill -9</code>"; that the same as "<code>kill -KILL</code>".)
:*** e.g.: <code>kill -KILL ''15476''</code>

:* '''pkill''' - send a signal to ''all'' processes that match the given criteria.
:** As with <code>kill</code>, you can choose from the HUP, TERM, and KILL signals. For <code>pkill</code>, it's often easiest to just start with the default signal (which is TERM).
:** To signal all of you processes, use the <code>-u</code> parameter along with your account name. (This will end ''all'' of your processes, including the shell you're using to run it.)
:*** e.g.: <code>pkill -u ''username''</code>

:* From within '''top''' command
:** Find desired process ID (PID)
:** press '''k''' (for ''kill'')
:** enter PID at prompt.
:** enter signal number to use (as with <code>kill</code> above, it often works best to try 1 (HUP) first, then 15 (TERM), followed by 9 (KILL).

===Modifying a Process's Running Priority===

Every process on our systems has a priority, which defaults to 0, signifying a neutral priority. Higher numbers, up to 20, represent ''lower'' priorities; the programs are being "nice" and allowing other programs to run more often. A priority of 10 is twice as nice as a priority of 5, and half as nice as a priority of 20. (Negative numbers, from -1 down to -20, represent very ''high'' priorities and are reserved for system processes.)

To change a process' priority, use the '''<code>renice</code>''' command:

<kbd>renice <var>priority</var> <var>pid</var></kbd>

"<var>priority</var>" gives the new priority for the process, from 1 to 20. Note that ''you can only ever raise the priority number''; once a process is at, say, 10, you can raise it to 15 but you cannot lower it to 5.

"<var>pid</var>" is the process ID for your process. You can get that from <code>top</code> or <code>ps</code>, [[#Monitoring Your Processes' Memory and CPU Usage with Linux Commands|as described above]].

To set a process' priority when you start it, use the '''<code>nice</code>''' command:

<kbd>nice <var>your program ...</var></kbd>
<kbd>nice -n <var>priority</var> <var>your program ...</var></kbd>

If you don't give a priority via the <code>-n</code> parameter, it defaults to a priority of 10.

==And, Worth Mentioning Again...==
: Please remember that because these are multiuser systems, ''other users could be logged into the system and could be affected if your running program exceeds the computer's resources.''