"new" and explain why.  Temporarily make the papers menu item say "new"
(for about two weeks, I think).

Add SMP support caveat.

Also print name of moused over node on the mode line.

described elsewhere ...

Note that until Jay approves the new menu config, mere users will *not*
see the new collaboration menu. Only STUDLY() users will see the new
menu, although everyone will see the rest of the front page menu changes
since they are fairly minor.

Update 4.7 -> 4.10.
Spelling check.

marked publically readable.

Anon users trying to find a project repo are silently redirected over
the ops web server.

Some really disgusting stuff in cvsweb.cgi; do not look!

Note we now install cvsweb and friends into ops:/usr/testbed/www/cvsweb

stuff that Jay does not want users to see.

basically, other titles from the same section.

lines of console log.

forthcoming ...

weeks back.

* utils/spewconlog.in: New script to ssh to the host tipserver and cat
  the console log for a node. In admin mode cats the .log file, while
  in mere user mode, cats the .run file.

* www/shownode.php3: Added a "Show Console Log" function.

* www/showconlog.php3: New script to invoke spewconlog backend script
  and dump the console log to the user.

Add some checks for 'free' nodes that are not allocatable.

	* db/audit.in: Include the list of nodes that are not reserved but
	have an eventstate that makes them unallocatable.

	* www/dbdefs.php3.in: Add POWEROFF and ALWAYSUP node states.

	* www/nodecontrol_list.php3: Add an asterisk next to the free
	count for type(s) that have free, but unallocatable nodes.

	* www/shownodetype.php3: If a node is free, but unallocatable, put
	a yellow ball next to its name instead of a green one.

turned on.

Okay, I implemented a primitive Knowledge Base! The current contents are
*all* the existing FAQ entries, which I entered manually. Here are the
details.

* My reason for doing this is that we need something very simple. The wiki
  is too much of a barrier, and its search capabilities are pathetic.

* The search page for the Knowledge Base is:

	https://www.emulab.net/kb-search.php3

  Fairly primitive keyword search. Turns out that mysql 4.0 has a bunch for
  really good text searching functions built in, but we run 3.23 ... so I
  had to roll it myself. So, its a simple keyword (space or comma
  separated) search, no regular expressions.

* Each DB record has a "faq_entry" flag, so creating the current FAQ on the
  fly from the DB is easy. See:

	https://www.emulab.net/kb-faq.php3

* In reddot mode, you can add new KB entries:

	https://www.emulab.net/kb-manage.php3

  The form is fairly obvious but here are details anyway:

    Section Name: Choose an existing title, or make up a new one.
    Title:        The title of the KB (or FAQ) entry.
    Faq Entry:    Check this box if the new entry should show up in the FAQ.
    X Ref Tag:    A token so you can refer to other KB entries by name,
                  instead of by its index. Within the KB entry you would
                  write: <a href=kb-show.php3?xref_tag=sometag>
    Body:         Whatever you like. I took the existing FAQ entries and
                  stuck them with no changes except for the xref_tag
                  mentioned about (since some entries referenced other
                  entries).

* Once you click on sumbit, you will see the entry as it will appear to
  users, along with a submenu to Modify/Delete/Add entries. You can modify
  the current entry from that menu. Mere users do not see this menu, only
  when in reddot mode.

* The intent here is that we can generate new entries really easy, right
  from email if you like (with appropriate <pre> or <xmp> tags around it).

* I have added sql/knowlbase-create.sql and a makefile target to
  generate that file when creating a distribution. I also added a section
  to install/boss-install to insert the entries into the new DB.

* I hooked the search function into the existing Search Documentation link.
  We know search both the Knowledge Base *and* the Documentation on doc
  searches. This probably needs a little more work to get right.

* I changed a lot of faq links to be more consistent and to reference
  the proper xref_tags (#swapping instead of #UTT-34).

in new project names.

Jay has "comments"), but I do not want it hanging around in my source
tree. Here is my mail message:

* The "My Mailing Lists" is context sensitive (copied from Tim's
  changes to the My Bug Databases). It takes you to the *archives* for
  the current project (or subgroup) list. Or it takes you to your
  first joined project.

* The showproject and showgroup pages have direct links to the project
  and group specific archives. If you are in reddot mode, you also
  get a link to the admin page for the list. Note that project and
  group leaders are just plain members of these lists.

* The interface to create a new "user" list is:

	https://www.emulab.net/dev/stoller/newmmlist.php3

  We do not store the password, but just fire it over in the list
  creation process.

  Anyone can create their own mailing lists. They are not associated
  with projects, but just the person creating the list. That person
  is the list administrator and is given permission to access the
  configuration page.

  This page is not hooked in yet; not sure where.

* Once you have your own lists, you user profile page includes a link
  in the sub menu: Show Mailman Lists. From this page you can delete
  lists, zap to the admin page, or change the admin password (which is
  really just a subpage of the admin page).

* As usual, in reddot mode you can mess with anyone else's mailman lists,
  (via the magic of mailman cookies).

* Note on cross machine login. The mailman stuff has a really easy way
  to generate the right kind of cookie to give users access. You can
  generate a cookie to give user access, or to the admin interface for
  a list (a different cookie). Behind the scenes, I ssh over and get
  the cookie, and set it in the user's browser from boss. When the
  browser is redirected over to ops, that cookie goes along and gives
  the user the requested access. No passwords need be sent around,
  since we do the authentication ourselves.

fails.

Bump date for papers menu item (noticed by Eric).

Added WORLDS 04 paper to pubs page.

Tweak the "My Bug Database" menu link so it points to a particular project
in the bugdb.

	* www/gotobugdb.php3: Pass on the project_title argument if one is
	given.

	* www/menu.php3: Make the bugdb link context-sensitive or have it
	link to the project the user was first approved for.
	Context-sensitivity is determined by whether or not a "pid"
	argument is given.

bugdb get updated correctly.

to work.

interface with cross machine login support.