Access to the interfaces implemented in the DCE shell must be secured in a consistent manner across all DCE shell commands.

REQT: Meet Other DCE 1.1 Goals

The DCE shell must meet the other DCE 1.1 cross component goals. These include but are not limited to the following:

1. Quality

   The DCE shell must meet the DCE 1.1 goals for maximum defects per KLOC,\*(f!

   1,000 lines of source code, not counting whitespace or comments.

   and for testing coverage.
2. Serviceability and Auditing

   The DCE serviceability functions for logging and messaging must be used. Any functions matching auditing event criteria that require the generation of an auditing record, must do so.

3. Code Clean-Up

   The DCE Code Clean-Up requirements for producing [ANSI C] compliant code, requiring the use of standardized library calls, and isolating machine dependencies must be met. (See [RFC 17] for details.)

4. Internationalization

   As the DCE shell will present an interface to a user, all messages it produces are subject to internationalization requirements. See [RFC 23] for details.

Lower Priority Requirements

REQT: Support for other DCE administrative functions

The motivation for a single DCE shell control program came mostly from experiences with administering DCE cells consisting of core components only, and as such, only core component functionality has been considered in great detail. Adding DFS and/or GDS support would certainly be useful in those cells in which these are run.

GDS administration is currently performed by a menu driven control program implemented using the curses interface. While it does offer menus (usually considered an improvement over a simple command line interface), it is still often difficult to use. It also possesses scripting capabilities, but scripts are quite difficult to generate as they involve creating full screen images. An item that is being considered for DCE 1.1 development is a command line interface to GDS. If this is done, then it should be as part of the DCE shell, or at least as a clone of the DCE shell meeting the same usability requirements as described above in the same manner as the DCE shell (i.e., the syntax must be the same).

DFS administration is currently performed by several command suites such as the bos, cm, and fts commands. They all take subcommands as arguments but are limited to command line input (i.e., you cannot enter a bos shell and enter bos commands as cdscp allows). There are about ten of these command suites in use. Currently the OSF development group does not use shell scripts to perform common functions requiring more than one command, however that is easily envisioned. In general, DFS is perfectly suited to the approach of implementing base routines in the DCE shell and then using a builtin language to extend the commands. The issue is whether there is time to implement this in DCE 1.1.

There are other core component administrative functions that have not been mentioned so far either. Particularly the security commands passwd_import and passwd_export. It is not clear that the DCE shell could affect the ease of use of the commands, as they require no user interaction. It may suffice to be able to invoke these commands via the shell escape mechanism described above. Access to these commands via the DCE shell could be useful for some commands such as including execution of passwd_export whenever a new user is added to the system.

REQT: Graphical user interface

It has already been stated that a GUI is less important than a command line interface for the first release of the DCE shell. However, a GUI of some form would certainly be a valuable addition to the DCE shell. What form should it take? It would be most desirable if a diagram of the running cell could be shown identifying all hosts and servers and allowing a user to click on an icon to display status or to select it for a specific action. It is believed that this type of interface will be difficult to develop in the available timeframe. However, design decisions that could allow for the future integration of such an interface should be made whenever possible.\*(f!

For example, often command line interfaces and GUI's have very different paradigms for their commands. GUI's usually are object oriented where some object is displayed in a window and actions are invoked on it, whereas command line interfaces are verb based where an action is invoked with an object as its argument.

A more practical GUI (to implement) would have a window used to display information, (e.g., lists of entries, principal, accounts, entries, directories) with pull down menus allowing actions. This would be very similar to the existing cdsbrowser and cdsedit.\*(f! The

The cdsedit program is a namespace browser that provides update capability in addition to browsing, as well as the ability to operate on ACL's on CDS objects. It was developed by the University of Massachusetts at Amherst, and has been demonstrated to OSF.

REQT: Command completion

Command completion would allow for both commands and perhaps some arguments (e.g., names in the namespace) to be completed in the same manner as csh and ksh allow for filename completion. This would also improve usability as is evident by the use that filename completion gets from the shells. It would be useful to implement, but other items are higher priority. Whether the namespace completion could be implemented with sufficient performance to make it useful is unknown. The extensibility requirements described above could make implementation of command completion difficult, particularly where user written commands take arguments which are to be subject to completion.

ISSUES

The items in this section require some further investigation or decision on their inclusion or exclusion from DCE 1.1 requirements.

Starting Servers

A useful feature of the control program would be the ability to start a server instance on a node. Currently most control programs do not support such a function. It would not be difficult to create such a command in the DCE shell, but its advantage over starting processes from a shell is not terribly clear, unless the DCE shell also has the capability to start servers on other hosts. An implementation of this function would probably require rpcd to be able to spawn processes (similarly to inetd), which is an item currently under consideration for DCE 1.1

Extending Existing Services

It is expected that in the course of DCE shell development, other inconsistencies between services (e.g., security models, server binding information, etc.) will be discovered that require a change or extension to an existing service. The issue is what should be done in these cases? By definition the DCE 1.1 release has the requirement that there be no incompatible protocol changes made. Given this rule, all that can be said is that each discovered change or extension must be handled on a case-by-case basis.

Selecting a Particular Server

For some commands, it is desirable to be able to identify a particular server for that command to be executed on. Examples include obtaining the status of a server, and forcing a replication update to occur. A manner of identifying a particular server on a particular host must be developed. The following are options:

1. UUID's
2. String Bindings
3. Namespace Conventions

Intercell Support

Are there any special requirements for supporting intercell configurations? Should the DCE shell be able to set up the trust relationships for intercell work? Should it be able to do this for both cells involved? Is there any other support required?

Use of Tcl

Tcl is an interpreter for a Tool Command Language developed by John Ousterhout at the University of California at Berkley [TCL]. It is a library that is meant to be linked into a tool program which provides a programmable language for the tool. It would provide an implementation of the programmability requirements described above. It also allows for the creation of new procedures which would provide an implementation of the extensibility requirements described above. In addition, Tcl provides certain features, such as detailed error handling, that meet some of the scriptability requirements. Using Tcl would require that the DCE base commands be implemented as Tcl base commands, which is essentially registering them with an interpreter and ensuring that uniform return codes and values are used.

The use of Tcl could make development of a fully functional DCE shell much easier. In fact, many of the requirements described in this document came about after having first learned about Tcl. If starting from scratch, many of the programmability and extensibility requirements will be difficult to meet in the available timeframe. Using Tcl, allows the requirements to be met with minimal work,\*(f!

In fact a DCE shell prototype already exists, using Tcl, meeting these requirements and implementing a DCE ping command.

In order to use Tcl, it will have to meet the same requirements of any code that OSF obtains from other sources. Here is a list:

1. Intellectual Property.

   OSF needs the right to work with the code as needed. This applies to copyright (and copyleft) restrictions. The best thing is for OSF to have unlimited right to use and distribute the code in whatever form we want, without complying with any rules with indemnification, meaning the supplier will defend us against intellectual property claims. (Our licensees ask us to do this for them.)

2. Functionality Limitations.

   It must meet the full functionality requirements of other DCE code. If it does not, we must add this to the code. Certainly the code will have to meet our coding guidelines, defect density, test coverage, reliability, etc. goals, just as if we'd written it ourselves. The current list of areas with known functional limitation concerns in Tcl code are:\*(f!

   The status in these items comes from email discussions with John Oustehout.

   1. Internationalization

      Currently Tcl is 8-bit clean with perhaps a few lingering exceptions. Unfortunately, there is little other internationalization support. The messaging support should not be difficult to add, but some codeset issues might be. The only datatype used in Tcl is the string. All commands return their results as strings. Of particular concern, are places in the code where the size of a character is assumed to be one byte. There are a few codeset dependent issues (e.g., case changing) but these should not be difficult to correct.

   2. Thread-safeness

      Tcl should be pretty clean in this respect. The fact that the interpreter is highly recursive forces it to be re-entrant; there aren't any global variables, except for environ, etc. However, it isn't safe to have multiple threads executing in the same interpreter at the same time, and trying to modify Tcl to support this would be pretty difficult. Thus either you can have separate threads each with its own interpreter, or you have to wrap each Tcl call with synchronization primitives to ensure mutual exclusion.

3. Version Issues

   There must be a strategy to stay in synch with new versions of Tcl as they become available. If we diverge from the main line (more than just compiling with CMA), then this could more than trivial. These problems have been solved before, in fact, DCE currently faces this issue with Kerberos code.

EXISTING CONTROL PROGRAM COMMANDS

The following are the commands supported by various control programs as found in the DCE 1.0.1 reference pages. The fact that they are listed differently (sometimes alphabetically, sometimes by function) indicates that there is a consistency problem.

This list is not intended to be a list of all the things that the DCE shell must do, but rather as a starting point for what it could do. Note that commands like help, quit, and exit are not listed.

rpccp

1. All entries

   add entry	show entry
   remove entry
   

2. Server Entry

   export	show server
   import	unexport
   

3. Groups

   add member	remove member
   remove group	show group
   

4. Profiles

   add element	remove profile
   remove element	show profile
   

5. Endpoint map

   remove mapping	show mapping
   

cdscp

add directory	list object
add object	remove directory
clear cached server	remove link
clear clearinghouse	remove object
create child	set cdscp confidence
create clearinghouse	set cdscp preferred clearinghouse
create directory	set directory
create link	set directory to new epoch
create object	set directory to skulk
create replica	set link
define cached server	set object
delete child	show cached clearinghouse
delete clearinghouse	show cached server
delete directory	show cdscp confidence
delete link	show cdscp preferred clearinghouse
delete object	show cell
delete replica	show child
disable clerk	show clearinghouse
disable server	show clerk
dump clerk cache	show directory
list child	show link
list clearinghouse	show object
list directory	show replica
list link	show server

acl_edit

abort	kill_entries
assign	list
cell	modify
commit	permissions
delete	purge
exit	substitute
get_access	test_access
help

rgy_edit

1. PGO's

   view	member
   add	delete
   change	adopt
   

2. Accounts

   view	delete
   add	cell
   change
   

3. Key Mgmt

   ktadd	ktdelete
   ktlist
   

4. Misc

   domain	auth_policy
   site	defaults
   properties	login
   policy	scope
   

5. Local Registry

   view	purge
   delete	properties
   

dtscp

advertise	set server principal name
change epoch	set servers required
change time	set synchronization hold down
create type clerk	set global set timeout
create type server	show all
delete	show all characteristics
disable	show all counters
enable	show all status
enable set clock	show {attribute-name}
set check interval	show global servers
set courier role	show local servers
set error tolerance	synchronize
set local set timeout	synchronize set clock
set maximum inaccuracy	unadvertise
set query attempts	update
set server entry name

sec_admin

become	lrep
change_master	master_key
delrep	monitor
destroy	site
info	state
initrep	stop

Existing Control Program Sizes

This appendix lists for each existing control program, each source file and its size as given by a count of the number of lines in each file. This is not KLOC but rather the output of the wc command.

rpccp

   80 cp_help.c
 3238 rpccp.c
 3318 total

cdscp Including msg, prs, and parser_aid

  232 accum_cmd.c
   74 argv.c
   99 attrgroup_actions.c
  236 attributes_list.c
  812 attrname_actions_cds.c
   57 baddest.c
  131 cdscp_help.c
   88 cmdblk_init.c
   97 confidence.c
  211 cp_cell.c
 1489 cprpc_clerk.c
  451 cprpc_emit_clerk.c
  452 cprpc_emit_server.c
 1180 cprpc_server.c
 1130 cprpc_util.c
  238 default_ent.c
  132 dnscp_args.c
  650 dnscp_credir.c
  351 dnscp_crekid.c
  120 dnscp_creobj.c
  105 dnscp_cresl.c
  275 dnscp_delkid.c
   79 dnscp_delobj.c
   79 dnscp_delsl.c
  425 dnscp_help.c
   93 dnscp_replica.c
   81 dnsinitflagstat.c
  228 dumpclerkcachecmd.c
  374 emit_cds_values.c
   58 emit_chdir_line.c
   89 emit_chdir_lines.c
   79 emit_exp_line.c
  103 emit_ext_line.c
   60 emit_group_line.c
   86 emit_member_lines.c
   61 emit_myname_line.c
  397 emit_one_line.c
   65 emit_parentcts_line.c
   69 emit_parentptr_lines.c
   52 emit_pptimeout_lines.c
  374 emit_ref_hdr.c
   65 emit_repchcts_line.c
   60 emit_repchname_line.c
   80 emit_replicapointer_lines.c
   65 emit_reptype_line.c
   64 emit_timeout_lines.c
   98 emit_tower_lines.c
  104 emit_towerset_lines.c
  270 entities_actions_cds.c
  279 entities_list.c
  617 err_list.c
  278 err_report.c
  140 exec_docmd.c
  235 exec_mgmt_cmd_cds.c
  192 failure.c
  242 filespec_actions.c
   54 find_base_name.c
   62 find_base_name_unix.c
  120 fmt_uid_for_print.c
  101 fopen2.c
  124 format.c
   89 format_chstate_for_print.c
   54 format_classversion_for_print.c
   84 format_confidence_for_print.c
   85 format_convergence_for_print.c
  159 format_fullname_for_print.c
   85 format_inch_for_print.c
   84 format_kindofent_for_print.c
   20 format_nodeid_for_print.c
   72 format_piboolstatus_for_print.c
   86 format_repstate_for_print.c
   90 format_reptyp_for_print.c
   73 format_simplename_for_print.c
   61 format_timestamp_for_print.c
   23 format_timestamp_with_time.c
  286 format_tower.c
   95 format_utcabs_for_print.c
  167 get_command.c
   73 hash.c
   39 islatin1print.c
  231 load_msg_file.c
  212 load_parse_file.c
  654 logging.c
  560 mgmt_main.c
  262 mgmt_parsing.c
 1044 msg.c
  354 msgfil.c
  457 msgfnd.c
  190 msgrea.c
  348 names_actions_cds.c
 1528 op_list.c
   88 operator_actions.c
  124 parse_command.c
  232 parser_aid_2.c
  259 parsing_support.c
  142 preferred_clh.c
   59 pretend_not_seen.c
  125 process_commands.c
 3576 prs.c
 2114 prscmd.c
  354 prsfil.c
  399 prsrea.c
  300 qarith_lib.c
  141 recognize_filespec.c
  126 replica_actions.c
  225 replica_support.c
  197 report_parse_error.c
   54 savemajorminor.c
  114 seconds_to_vmsdeltatime.c
  179 spaces.c
  110 spawn_ncl.c
  149 startup_file.c
   84 stubs.c
   17 symsub_actions.c
  244 time_actions.c
   59 validate_tower.c
  910 visit_cds.c
  153 with.c
  801 cds.cdt
   32 parser_aid_2.cdt
  744 mgmt_msg_cds.txt
34388 total

acl_edit

  237 acl_edit.c
   46 acl_edit.h
 2218 deif.c
  296 deif.h
  118 deif_err.c
 1408 tty.c
   56 tty_base.h
 4379 total

rgy_edit

  217 eif.c
  160 eif.h
  637 eif_acct.c
   94 eif_acct.h
  717 eif_def.c
  117 eif_def.h
  799 eif_pgo.c
  125 eif_pgo.h
  411 eif_prop.c
  119 eif_prop.h
  357 eif_site.c
  120 eif_site.h
   30 eif_util.c
   44 eif_util.h
 8853 ek_db.c
  679 ek_db.h
   30 ek_error.c
   32 ek_error.h
   83 ek_glob.h
  391 ek_site.c
   70 ek_site.h
  181 ek_types.h
 1992 ek_util.c
  597 ek_util.h
  438 form.c
  223 form.h
 1734 tty.c
 2126 tty_acct.c
   67 tty_acct.h
   38 tty_base.h
  184 tty_conf.c
  213 tty_conf.h
  283 tty_def.c
   45 tty_def.h
   30 tty_err.c
  125 tty_err.h
  793 tty_io.c
  261 tty_io.h
  328 tty_keytab.c
   42 tty_keytab.h
 2163 tty_pgo.c
   85 tty_pgo.h
 1139 tty_prop.c
  110 tty_prop.h
  234 tty_util.c
  115 tty_util.h
27631 total

dtscp Including libprs_threaded.a

  151 allocate_mem.c
 2902 dtsscp.c
  101 dtsscp_ultrix.c
 2222 prscmd.c
  358 prspre.h
  412 prsrea.c
  849 dtsscp.cdt
 6995 total

sec_admin

Note that this file does not include all the replicated security functions.

   931 sec_admin.c
   931 total

libsecutil.a Included in acl_edit, rgy_edit, and sec_admin

   203 args.c
   338 commands.c
   171 auth_test_util.c
   712 total

REFERENCES

[PORTG]

DCE Porting and Testing Guide, Open Software Foundation, 1992.

[POSIX.2]

IEEE Std 1003.2 - 1988, Portable Operating System Interface -- Shells and Utilities

[RFC 17]

H. Melman, DCE Code Clean-Up Requirements, December 1992.

[RFC 23]

R. Mackey, DCE 1.1 Internationalization Guide.

[RFC 24]

R. Salz, DCE 1.1 Serviceability Proposal, November 1992.

[RFC 25]

E. McDermott, DCE Auditing Design and Strategy, December 1992.

[TCL]

Ousterhout, J. Tcl: An Embeddable command Language. Proc. USENIX Winter Conference, January 1990, pp. 133-146.

AUTHOR'S ADDRESS

Howard Melman		Internet email: melman@osf.org
Open Software Foundation		Telephone: +1-617-621-8989
11 Cambridge Center
Cambridge, MA 02142
USA