GitLab

<= len(max other one), except for a 'new' flag.

Reorder and tweak new pubs.
In main doc menu tell users they can browse the KB also.

Remove comment about old papers, new posting.

font, font size, etc as the main menus.

The non-main style (devel trees) is a little broken; style files are
really a pain, or maybe its just our style files that are impossible
to understand. Or maybe I'm just a dope.

from RSS aggregators such as Firefox and Google Reader.

This came out of an idea discussed with Chris Alfeld and Jay.

Need to delete latter after ~2 weeks.

I can say.

Set $noheaders=1 in iframed pages.

subdirs.

frustration until I realized that style.css does not actually come
from your devel tree, but somehow comes from the main tree.
But, along the way I did some reading about style sheets, and now I
know just enough to be dangerous.

Anyway, whats this revision about? No comment. You figure it out.

* Minor bug fix contributed by Chris.

* Do not spit out a Collaboration header if none of the Collaboration
  tools are turned on.

* Moved the Free PCs indicator to the right of Node Status, as per
  Jay's request.

Ready for local people to play with.

The current implementation is that we munge the mysql DB on ops directly,
underneath jabberd. We add/del users from the authreg table, and set up
buddy lists in the roster-items and roster-groups tables. modgroups will
invoke the modjabberbuddies whenever a user is added or removed from a
group, although currently I am building buddy lists for just the top level
projects.

The "My IM" link in the collaboration menu will tell the user their
jabber ID on the Emulab chat server (jabber.emulab.net) and also give
them their plain text password to plug into their chat client.

I also installed a java applet (Jeti) that is a simple chat client that
I found off the jabberware page. Like all applets, it exhibits a degree
of flakiness, but I really do not expect too many people to use it.

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

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.

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).

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.

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

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.

interface with cross machine login support.

comes from the current date. The version from from sql/database-migrate.txt.
Also commit changes to front page. I still need to hook it into the
install process.

have the user go through a set of hard to explain steps, just push
them through it using the web interface.

* New sitevars to control a little state machine used by the web
  interface.

* When first setting up a testbed, the sitevar value will force the
  web interface to present the user with a single menu option "Create
  New Project" and the "Home" link will take the user to that page.
  The user is instructed to login is as elabman.

* The user fills in the form as directed in setup-ops.txt. Even though
  he is logged in as elabman, the newproject form has been altered to
  operate as if no one is logged in. I also default a bunch more of
  the fields in this case.

* The user submits the form. Rather then pend the new project, just
  jump straight into approveproject. That grinds along as usual, and
  when it is done, the elabman account is frozen and the user logged
  out. The user gets a link inviting him to log back in as the user
  just created.

* Side effects of this new process:

	* The user is made an admin user (admin=1) automatically.
	* The user is added to the emulab-ops project as group_root.
	* The user verification process is skipped.
	* The user is added to the unixgroups wheel and tbadmin.

* I reworked this entire section of setup-db.txt ...

* The user still needs to give himself a real shell and password on
  boss, but I left that for the user to do explicitly. I also drop in
  a pointer to the shellonboss.txt. I might automate this part too at
  some point. Not sure yet.

into the Wiki when clicking on the My Wiki's link. Works like this:

* The My Wiki's link points to new page, gotowiki.php3, on boss.

* The gotowiki page looks for a new cookie in the user's browser
  which holds a key (the usual random data run through md5).

* If the key does not exist, generate it and store it in the user
  browser (expires when browser is closed or emulab login times out).
  Also invoke backend script wikixlogin, which will send the key over
  to the wiki server (via ssh), which will write the key into a file
  named by the user account.

* The user's browser is redirected to the wiki server's login script
  (twiki/bin/newlogon), but instead of username and password, we send
  over username and key (as well as redurl= parameter which is the
  page on the wiki server to redirect to later).

* The new login script looks for this case, and opens the file named
  by the user and compares the key it gets with what is in t...

for the near future. Two big changes:

* Add WikiOnly accounts. An external user can register for an account on
  the wiki. Rather then use the registration stuff that comes with TWiki,
  redirect to new Emulab web page so we can manage all of the wiki accounts
  from one place. I modified the joinproject page to spit out a subset of
  the required fields so that its simple to get a wiki only account (just a
  few things to fill in).

  In keeping with current security practices, we still generate a
  verification email message to ensure the email address works. However,
  when the user completes the verification, the wiki account is created right
  away, rather then waiting for someone to approve it (since that would
  defeat the entire point of the wiki).

  Aside: I have not thought much about the conversion from a wiki-only
  account to a real account. That is going to happen, and it would be nice
  if that step did not require one of use to go in and hack the DB. Will
  cross that moat later.

  Aside: Rather beat up on the modify user info page too much, I continue
  to spit out the same form, but mark most of the fields as not required,
  and allow wiki-only people to not specify them.

* Both the joinproject and newproject pages sport a new WikiName field so
  that users can select their own WikiName. I added some JavaScript to
  both pages that generate a suitable wikiname from the FullName field, so
  that as soon as the user clicks out of the FullName, a default wikiname is
  inserted in the field.

  Both pages verify the wikinames by checking to make sure it is not
  already in use, and that it meets the WikiRules for WikiTopic names.
  (someone please shoot me if I continue to use WikiNotation).

Wiki support is turned on in the defs file with a WIKISUPPORT=1 directive.