|Search Duke CSL||
To change your password, run the folowing command at the UNIX/Linux command-line prompt:
You will be prompted for your current password, and then for your new password (you'll have to type the new one twice). If your new password isn't sufficiently obscure, it will be rejected.
To change your login shell run the UNIX/Linux command:
You will be prompted for your password, and for the full path to the shell of your choice.
You can check your group membership by using the UNIX/Linux groups command. Note that when you are added to a new group, you may need to login again for the new group membership to take effect.
You can check the membership of a particular group by using the getent command; for example to find the users belonging to the group cps131, you would use the following command:
% getent group cps131 cps131:*:1131:fred,jones
where users fred and jones are the only members of this group. Note that this will not include group members who have the group ID as their primary group number in their passwrod entry
Department members make frequent use of UNIX groups to share files among group members. It is possible to set up shared directories such that all files created within the directory inherit the default group, (see the discussion about the group ID bit in the chmod man page), but it is up to the individual users to make sure the files have the proper permissions. This can either be handled manually, using the chmod command, as shown below:% chmod g+w newfile
Alternatively, the user can affect all file creation permissions by changing their umask to 002 (the default is typically 022. Note if this method is chosen, this will affect all files created by the user!
If you are having trouble connecting to a department machine via ssh, please try connecting to login.cs.duke.edu first. Access to individual desktops is not guaranteed; these machines might be down for repairs or even be replaced entirely!
If you are experiencing problems logging into a known-available machine, particularly with the newer, Linux-based machines, you may have a problem with you account configuration files, or dot-files. Please see the Linux FAQ for more information.
With the recent addition of Linux desktops to the department, some users have reported problems accessing filesystems, particularly those under the /usr/project hierarchy. In most cases, this is simply due to a difference in the browsability feature of the automount utilties on Solaris and Linux. In short, the Solaris automounter keeps a record of the recently mounted filesystems while the Linux automounter does not. On Linux machines, you will need to access the filesystem (e.g. change directory into it) in order for the directory to be visible.
You can set up a crontab on one or more departmental UNIX systems in order to run regularly scheduled, recurring jobs (commands). We recommend that you use the the server cron.cs.duke.edu for your crontab, as opposed to individual desktop workstations, as desktop workstations cannot be guaranteed to be available, and if these machines are being service or replaced, the crontab files may not be recoverable.
Please see the crontab man page for details on setting up your personal crontab.
Traditionally in UNIX, filenames and other strings are sorted via a straight ASCII sort, where all uppercase characters precede all lowercase characters. You may have noticed that under Solaris, in some windows, you type ls, and the files sort as if the sorting were case independent. This has to do with Solaris' POSIX locale features. By default, the init(1M) process starts shells with the locale environment variables set to en_US, which results in this unaccustomed sorting behavior. On the other hand, some windows started by user actions do not inherit this environment, and display traditional UNIX sorting behavior.
To get the old traditional UNIX sort order, just make this setting in your environment, here shown in csh syntax:
setenv LANG C setenv LC_COLLATE C
core files are typically created when a program crashes and the contents in memory are written to a file for debugging purposes. Some programs, particularly many screensavers appear to crash frequently and can litter your login directory, also taking a significant portion of your file quota. You disable these by running the following commands, or adding them to the appropriate login configuration files.
At times, users report problems logging into their desktop machines using a graphical window manager when remote logins work fine. This problem sometimes occurs when the window manager software on a machine has been updated, and the user's configuration files are out of date. Often this can be easily remedied by removing these files (or changing the name of these, such as appending .old to them) for your particular window manager, and letting the software create a fresh set of files for you.
For the KDE window manager, users would remove the .kde directory, located in their home directory. For the Gnome window manager, users should remove the .gnome and .gconf and .gconfd directories. Note Gnome seems to have more and different versions of configuration directory names so users might need to exercise a little flexibility in determining which things to remove/rename.