GitLab

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 the file.
  If they match, the user login succeeds and the browser is once again
  redirected, but this time to the page it wants on the wiki server.
  If the key does not match, the browser is redirected to the login
  page (so user can enter username password normally). The redurl
  parameter is passed along as well.

* Subsequent clicks on My Wiki's will not need to invoke the backend
  script, since the cookie will be in the browser.

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.

web interface you are talking to!

icon next to the news link.

Not advertised is the fact that if you add "refreshrate=XXX" to any
page URL, that page will refresh every XXX seconds. Obviously, you
wouldn't to do this on the Begin Experiment page!

My Emulab page when logged in.

soeftware called swish-e since webglimpse was broken, did not install
out of the box, no longer being maintained by the authors, and
generally a pain in the ass.

swish-e is probably overkill, but it works and can be configured and
run from a single configuration file (swish.conf.in).

I've removed the advanced search form and replaced with simple form.
I can bring back advanced stuff if needed, although better to wait
until the swish-e port is upgraded and there is better backend support
for generating the html output.

There is a backend script called websearch that is called from the php
search page. It invokes swish and spits out html that is amenable to
being inbedded in our existing page layout (we were not able to do
that with webglimpse).

Also forgot to check in update date for software.

longer referenced so lets not confuse us.

the paper effort for everyone. I've redirected everything to
beginexp_html.php3 (the front end to the XML version), including the
plab and bui pages.

I've stuck a redirect in the old beginexp.php3, to make it easy to
bring back the old version in case something goes wrong. Just comment
out the lines at the top and reinstall, along with changing the other
links to it.

All sites now link to us. Eventually use an imagemap.
Note that right side is not hot yet.

I've intentionally left this list different (and shorter) than the one
'normal' admins get so that no one is tempted to do too much with such
a user.

more testing).

In menu, remove NEW icon from Plab until it's working again.

link in the sidebar.

see this new page. That allows me to inflict pain on testbed
developers while we work out any kinks. These new pages implement an
XML interface to experiment creation.

Some new files:

beginexp_html.php3: A wrapper for the actual beginexp form. This page
includes the form, and then invokes the XMLRPC backend page.

beginexp_form.html: The original form code, split out from beginexp
and turned into a module that can be included into another file.  It
is slightly reorganized to make it easier to include as a module.  The
idea is that the plab_ez form will be recast in this model, reducing
some redundant complexity.

beginexp_xml.php3: The XML backend. The idea is that the html page
packages up the form arguments as an XMLRPC message, and invokes this
page with the XML goo encoded in the URL. It also passes along the
uid/cookie so that the authentication happens properly (https of
course). The page decodes the URL into PHP datatypes, and does much of
the same argument checking that beginexp used to do. Errors are stored
up in the same manner, but instead of spitting back html, it now spits
back a "structure", encoded in XML so that the _html page can put up a
new form. Basically, all output is sent back via an XML encoded
structure and displayed in a form that the invoking script deems
appropriate.

This gives us a pure XMLRPC interface, which we wrap with a form interface
so that it looks just like it did before.

The next step is to provide an alternate front end, but that will require
some certificate stuff that I have not worked out yet.

Oh, one more item. The syntax check stuff has been altered a bit.
Instead of invoking the beginexp page, which meant a zillion special
tests, I now invoke nscheck.php3 directly from the button. Took a few
extra lines of Javascript to do this, so watch out for problems there
too.

some browsers.

a bit of whitespace so that the menu is easier to read, and shrink
the font down a bit.

Move all admin options to one place in the menu.

All users now the link to the planetlab_ez page.

Comment out the survey for now - we can resurrect it if we ever have
new questions to ask.

use pcplab nodes.

Added GETUSERVIEW(), which determines the current user's default view
- either the normal one, or the planetlab one.

Add a logout botton to WRITEPLABTOPBAR()

Added an 'Approve users' button to WRITEPLABTOPBAR()

Added WRITEPLABBOTTOMBAR() to put some stuff for planetlab users across the
bottom of the page.