UBiquity

UBiquity is a computing environment that provides a consistent, logical view of computing resources. It is designed to allow access to resources from different computing domains, and can be customized to meet the needs of each node while still insuring a common tool set across all of them. It attempts to present a familiar user interface on all computer systems, regardless of type, so that users can comfortably use different types of computers for different applications.

UBiquity is also designed to maximize system administration effectiveness by using the network as a tool to propagate software, shared resources, and operating system upgrades.

(Note: In the context of this web page, please note that we use the term "Unix" to refer to Unix-branded operating systems such as Oracle's (formerly Sun Microsystems') Solaris as well as Unix-like operating systems such as the various distributions of GNU/Linux and the various dialects of BSD Unix.)

To put it another way, UBiquity does:

  • Provide cross-nodal access to home directories, project directories, software directories, email, and other such resources.
  • Provide a consistent quot;look and feel" for workstations and PCs. We have three standards currently in use:
    • The Common Desktop Environment (CDE) desktop, used on Unix-based workstations from Sun Microsystems and Hewlett Packard;
    • The Microsoft Windows XP desktop environment; and
    • the GNOME desktop environment, which is native on many GNU/Linux distributions such as the Red Hat 9 distribution used by SENS, and which has been ported to Solaris, HP-UX, and IRIX. A version even runs on Microsoft Windows XP-based systems through the use of the Cygwin/CyGNOME software packages.
  • Provide communications services across platforms, so that PC users can access Unix home directories and Unix email directories, and so that Unix users can access PC programs via the Citrix software (a form of Microsoft Windows "time-sharing") or a similar mechanism.
  • Provide access to commonly-used tools across platforms, such as a Unix user running Microsoft Word via Citrix, or a Microsoft Windows user running ANSYS via XWin32 or Cygwin.
  • Minimize the number of operating systems in use on each platform. In the past, Node Sun systems ran about 10 different versions of or SunOS/Solaris; a major effort of the UBiquity project involved upgrading all of them to Solaris 2.8. A common operating system insures that different workstations don't behave in different ways to the users, eliminating a common source of confusion and frustration. Similarly, we have standardized on Microsoft Windows XP, Professional Edition, and UBLinux (a customized version of Red Hat Enterprise Linux 4) for our lab PC systems.
  • Allow individual nodes to limit access to systems in their nodes via local password files, or to open up their environment to the University community through the use of the CIT password file. In either case, login names and numeric user IDs are assigned by CIT and consistently used by all domains, so that domain resources can be shared at a later date without imperiling the security of the domain. This password information is used in both the Unix and PC environments for consistency and reduced administration costs.
  • Allow as much or as little dependence on global (CIT) resources as deemed necessary. For example, nodes may choose to have their own mail server, or may elect to use the CIT mail server for email access on their client workstations and PCs.
  • Allow individual nodes to tailor their environments to meet the needs of their user base, but within the overall UBiquity structure. Example: the GNOME desktop will be standard, but individual nodes may add "pop-up" menu items for applications that are specific to their environment.
  • Allow individual users to tailor their environments, but "caveat hacker" rules apply. We will only actively support the "standard" environment, but will try to help these users if we can.

On the other hand, UBiquity does not:

  • Completely homogenize the workstation environment. A workstation in an Engineering lab will have Engineering home directories and resources available by default; an NSM workstation will have NSM-specific resources available by default. In addition, these systems are optimized for the environment in which they reside. Extra-nodal resources will be easily accessed through standardized directory naming conventions.
  • Restrict nodes or users from using other resources. For example, there are many Macintoshes in the Mathematics department, and UBiquity does not dictate their removal from the node. Also, some departments may need customized systems to interface with instrumentation or to perform other mission-specific needs.