Psycho Cluster Policies

It is the responsibility of each member of the CNBC to be familiar with Carnegie Mellon University policies and guidelines. In addition to the Psycho Cluster policies, the following resources are available to assist you in understanding community expectations:

Note from the CNBC Computer Administrator

As the CNBC Manager of Computing Resources, it is my desire to provide an efficient, reliable, shared, high performance computing resource for the CNBC research community. In order accomplish this, I need your help with two things:

1) If you have a need or problem, I ask that you contact me so I can work with you at resolving it. I cannot resolve issues and make changes if I don't know there is a need or problem.

2) Become familiar with the environment and tools of the cluster. This twiki and the following policies and guidelines are intended to help everyone accomplish their objectives. Please take the time to read and understand the pages on the twiki that pertain to the cluster. If you find that it is lacking in some way, please contact me and I will do my best to improve this resource.

Thank you in advance for your understanding and cooperation.

Respectfully,David Pane

The Reasonable Person Principle

This is part of the unwritten culture of CNBC Computing. It holds that reasonable people strike a suitable balance between their own immediate desires and the good of the community at large.

  • Everyone will be reasonable.
  • Everyone expects everyone else to be reasonable.
  • No one is special.
  • Do not be offended if someone suggests you are not being reasonable.
Reasonable people think about their needs, and the needs of others, and adjust their behavior to meet the goals of a common good for the community, (i.e. expressing what you want to do, but accepting and accommodating the needs of others).

Not all people share the same model of reasonableness, so disagreements inevitably occur.

Under the reasonable person principle, the first thing to do is work it out privately. Indeed, many people would find it reasonable to bring in third parties before trying personal discussion.

More generally, the reasonable person principle favors local, unofficial actions over formal administrative ones. It assumes that people will be responsive when reminded of a conflict or asked to re-examine their behavior. It encourages requesting rather than demanding. And it leaves some room for the difference of opinion.

User Support

All users of the CNBC Cluster should send email with their account application, support requests and questions to or phone me at 412-268-7108. Please include your cluster username in your email.

The SCS Facilities has various types of accounts that map to various levels of user support. Most CNBC Cluster users have SCS Facilities lowest tiered account. This means that these users do not have the level of support where they can submit help requests directly to the SCS Facility help desk. If you have a SCS account due to being affiliated with the SCS department, you may have a full support account. However, everyone who is a user on the CNBC Cluster should submit Psycho cluster support requests to the CNBC administrator.

Account Policies

The cluster is available to lab members and collaborators of the PI paying the CNBC cluster support charges but should should be done within reason. Work done on the cluster should be for the research done within the bounds of the collaboration. Anything short of this would be taking advantage of a resource that is paid for and supported by the CNBC.

Each user must have their own user account on cluster. Multi-user accounts are NOT allowed. We support lab UNIX groups to enable sharing of data between lab members and collaborators.

There is no firewall between the SCS network and the internet ( Why?). As a result, the network gets scanned several hundred times per day. Every year, there are numerous break-ins to SCS hosts. The vast majority of these break-ins happen because of:

  • Poor passwords.
  • Passwords that are sent over the network unencrypted and get sniffed.
SCS has an extensive page on choosing a password. see

Keep your passwords secure! To keep your passwords secure:

  • Always use encrypting connections when sending passwords over the network. Note that passwords may still be eavesdropped through keyboard and tty sniffers even if you do use encrypted network connections.
  • Avoid typing passwords at untrusted hosts.
  • Don't use the same passwords for different purposes.
  • Use good passwords.
  • Don't share your passwords with others.


The following offsite links will open in a new browser window:

CMU Computing Services Information Security Office
Guidelines for secure computing at CMU
Security advisories and lots of good information.
Security Focus
Security news, and home of various mailing lists, including bugtraq archives.
SANS Institute
See their reading room for a large collection of security-related articles.
The home of Nmap, along with other security-related resources, including some good lists of security tools.

Connections and File Transfers

Whenever you connect to the cluster or use the network, you should assume that somebody could be eavesdropping on the packet data that you send and receive. For that reason, whenever you are transmitting sensitive data, such as passwords, over the network, you should use some form of encryption to protect your data.

For remote logins: Use SSH for logging into the cluster. This will protect your network traffic from being snooped in transit.

Data transfers must also be done over a secure connection.

Only active users on the cluster will have access to the data on it. If a user needs to share data with a someone that doesn't have an active account on the cluster, then the data should be transferred to a server which allows guest accounts.

Options for sharing files:

Cluster Usage Policies

With a few exceptions, users are asked to avoid processing on the head node. Small very short jobs that use very little memory or cpu usage is acceptable. If you have questions about this, please ask.

A couple important reasons why we would like you to avoid processing on the head:

1) This is the only way users can log onto the cluster. If the head node resources are being used for processing, users will see slow responses and may find it difficult to even do a directory listing.

2) If the processing takes too much memory or cpu, the head node could crash. This would cause an inconvenience for everyone using the cluster at the time of the crash. If the work is done on a compute node, only the users on that particular compute node will be burdened.

File Storage Policies

The storage on the cluster was put in place so users could utilized enterprise grade storage for their computational needs. The cluster is not intended to be used for a file server, backup server. It is recommended that only data used or processed on the cluster should reside on the cluster.

More details on File storage can be found here:

-- David Pane - 2015-06-01


This topic: CnbcUsers > WebHome > ClusterPolicies
Topic revision: r3 - 2015-08-03 - dpane
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback