ARSC HPC Users' Newsletter 292, May 28, 2004
System And Account Security
[ Thanks to Derek Bastille for this reminder... ]
As many of you may know or have seen, there has been an increase in activity on the internet recently that is aimed at gaining unauthorized access to computing centers. Many of the attacks have been aimed at individual workstations. If the attacker gained control of a user's workstation or account, he or she could then attempt to access supercomputers or other systems, masquerading as the legitimate user.
Many of the attacks rely on either un-patched workstations or PCs with old, known vulnerabilities or on folks using insecure applications like plain telnet to connect to systems. Others rely on social engineering and on the "trust" relationships between systems.
Given this activity, it is critical that you, as a user, remain aware of how you are connecting to your workstations and to the supercomputers, and of your general computing environment.
- Regardless of your workstation OS, always keep up to date on all patches, hot-fixes and updates for your system
- Never use insecure applications such as telnet or ftp where your password is passed "in the clear" to connect to remote systems
- Change your passwords regularly and take care to pick "good" passwords ( http://www.arsc.edu/support/policy/password.html )
- Be extra observant of your environment. Things such as unexplained "dot" files or hidden directories, unexplained disconnects, and odd system behavior can all be indicative of an attack or a compromised system
- Never account share. Once you lose track of who logged into which account and when, it becomes very difficult to determine if an access is legitimate
- Never open email attachments from unknown senders
Most of all, don't be afraid or embarrassed to tell your system administrator that there's something you don't understand about your account or that you think your account may actually have been compromised. System administrators much would rather spend a little time verifying that a problem is not serious than spend a much longer time cleaning up after an incident that caught them by surprise. Similarly, if you have any questions about system or account security, contact your center's Help Desk for answers, tips, and pointers.
SX-6 Removal from ARSC
Sad but true, the SX-6 which has graced our machine room for two years is to be removed from ARSC at the end of next month (June, 2004).
This system has been available, through ARSC, to our users and the wider U.S. HPC community for benchmarking and testing. ARSC-sponsored rime users have used this opportunity to port tools to the SX-6, prepare codes for runs on the Japanese Earth Simulator, and to simply benchmark codes on this unique vector architecture.
During its stay in Alaska, "rime" has been jointly managed by Cray Inc. and ARSC. It is returning to Chippewa Falls where it will be managed solely by Cray Inc.
ARSC-sponsored rime users: check the news items on rimegate for specific updates and information. Contact us at email@example.com as questions arise.
Crash Trace-Back on the X1
Trace-back on program abort is available under UNICOS/mp 2.4 (installed on klondike). You must enable it, by setting an environment variable, prior to running your executable . When enabled, if your program crashes, the OS will tell you the subroutine call in which the program aborted and its call tree. Formerly on the X1, this information was only available by running the core file through a postmortem debugger (totalviewcli).
From Cray's release notes:
Enable traceback by setting the interim environment variable TRACEBK to the number of stack frames you would like printed (the maximum is 32).
C shell syntax: % setenv TRACEBK 8 % mpirun -np 4 ./a.out Korn shell syntax: % export TRACEBK=8 % mpirun -np 4 ./a.out
Iceberg Allocations, Charging, and Loadleveler Classes
As noted in the last issue, beginning June 1, 2004, all usage in iceberg's foreground classes (standard, data, debug, lpage, p690, special, and single) will be counted against your allocation. Jobs running in 'bkg' will not be charged.
You're encouraged to read "news queues" on iceberg. It gives details on all the loadleveler classes, their purpose, and how to use them. From that news item, here's information on four classes:standard
'standard' the most general-purpose class. It allows jobs up to 256 processors (32 8-way p655 nodes) to run for 8 hours. Please use 'not_shared' node_usage in this class.p690
'p690' starts up to 32 processor jobs on the p690 nodes. Performance will be best with all processors on the same node. Please use 'shared' node_usage in this class.data
'data' is for data transfers to/from the storage server (seawolf). The $ARCHIVE directories are only mounted on the interactive nodes (b1n1 and b1n2). Please use 'shared' node_usage in this class.bkg
'bkg' is for background work. Jobs running in this class will receive lower starting priority but runtime will not be charged against allocations. During periods of high activity this class may be drained.
ARSC Summer Tours : Wednesdays 1pm
Jump-in to virtual reality at the ARSC Discovery Lab. Take a virtual tour of the home to some of the fastest supercomputers in the world, and check out the latest 3-D applications in development at UAF.
The tour meets at the back loading dock of the library (see map). From the Taku visitor lot, walk up the path and veer right on Tanana Loop. Cross at the first crosswalk, take an immediate right. First loading dock on the left. Reservations are required for groups of ten or more.
2004 Tour Schedule:
June 2-August 25: Every Wednesday, 1 p.m.
Quick-Tip Q & A
A:[[ I want the X1 and SV1 compilers to completely unwind this loop nest: [[ [[ do i=1,3 [[ do j=1,3 [[ do k=1,3 [[ ... [[ enddo [[ enddo [[ enddo [[ [[ There's no "!DIR$ UNWIND" directive, however. Any suggestions? !DIR$ UNROLL 3 do i=1,3 !DIR$ UNROLL 3 do j=1,3 !DIR$ UNROLL 3 do k=1,3 ... enddo enddo enddo (It's not enough to just say "UNROLL"... you've got to give it the 3.) Q: How can I find out what this means? ftn-6205 ftn: VECTOR File = potnl1temp.F, Line = 392 A loop starting at line 392 was vectorized with a single vector iteration. ftn-6003 ftn: SCALAR File = potnl1temp.F, Line = 393 A loop starting at line 393 was collapsed into the loop starting at line 392. (This was output by Cray ftn on my code, when I gave ftn the "-rm" option, for loopmark listings.)
[[ Answers, Questions, and Tips Graciously Accepted ]]
Ed Kornkven ARSC HPC Specialist ph: 907-450-8669 Kate Hedstrom ARSC Oceanographic Specialist ph: 907-450-8678 Arctic Region Supercomputing Center University of Alaska Fairbanks PO Box 756020 Fairbanks AK 99775-6020
Subscribe to (or unsubscribe from) the e-mail edition of the
ARSC HPC Users' Newsletter.
Back issues of the ASCII e-mail edition of the ARSC T3D/T3E/HPC Users' Newsletter are available by request. Please contact the editors.