1. 06 Sep, 2005 1 commit
  2. 02 Sep, 2005 3 commits
  3. 01 Sep, 2005 2 commits
  4. 31 Aug, 2005 2 commits
  5. 30 Aug, 2005 3 commits
  6. 25 Aug, 2005 1 commit
    • Timothy Stack's avatar
      · 25ca9681
      Timothy Stack authored
      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.
      25ca9681
  7. 23 Aug, 2005 1 commit
  8. 18 Aug, 2005 3 commits
  9. 17 Aug, 2005 1 commit
    • Leigh B. Stoller's avatar
      The Emulab Knowledge Base! · 6f08c442
      Leigh B. Stoller authored
      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).
      6f08c442
  10. 16 Aug, 2005 2 commits
  11. 15 Aug, 2005 1 commit
    • Leigh B. Stoller's avatar
      The bulk of the mailman support. Still not turned on by default (cause · a64593f3
      Leigh B. Stoller authored
      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.
      a64593f3
  12. 09 Aug, 2005 1 commit
  13. 29 Jul, 2005 1 commit
    • Kirk Webb's avatar
      · b9dc258e
      Kirk Webb authored
      Bump date for papers menu item (noticed by Eric).
      b9dc258e
  14. 28 Jul, 2005 1 commit
    • Kirk Webb's avatar
      · a1a504a2
      Kirk Webb authored
      Added WORLDS 04 paper to pubs page.
      a1a504a2
  15. 27 Jul, 2005 1 commit
    • Timothy Stack's avatar
      · e88a8ea6
      Timothy Stack authored
      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.
      e88a8ea6
  16. 22 Jul, 2005 3 commits
  17. 21 Jul, 2005 3 commits
  18. 18 Jul, 2005 2 commits
  19. 13 Jul, 2005 1 commit
  20. 07 Jul, 2005 3 commits
  21. 01 Jul, 2005 2 commits
  22. 30 Jun, 2005 2 commits