1. 14 Sep, 2005 1 commit
    • Mike Hibler's avatar
      Changes related to allowing seperate 'fs' (file server) node. · c53d5827
      Mike Hibler authored
      Entailed new instructions for manual setup as well as integration into
      elabinelab framework.  First, the manual path:
      
      setup.txt, setup-boss.txt, setup-ops.txt and new setup-fs.txt:
          Updated to reflect potential for separate fs node.  The org here
          is a little dicey and could be confusing with ops+fs vs. ops and fs.
          Has not been field tested yet.
      
      */GNUmakefile.in: new fs-install target.
      
      configure, configure.in, defs-*:
          Somewhat unrelated, make min uid/gid to use be a defs setting.
          Also add config of fs-install.in script.
      
      boss-install.in, ops-install.in and new fs-install.in:
          Handle distinct fs node.  If you have one, fs-install is run before
          ops-install.  All scripts rely on the defs file settings of FSNODE
          and USERNODE to determine if the fs node is seperate.
      
      utils/checkquota.in:
          Just return "ok" if quotas are not used (i.e., if defs file FS_WITH_QUOTA
          string is null.
      
      install/ports/emulab-fs:
          Meta port for fs node specific stuff.  Also a patch for the samba port
          Makefile so it doesn't drag in CUPs, etc.  Note that the current samba
          port Makefile has this change, I am just backporting to our version.
      
      Elabinelab specific changes:
      
      elabinelab-withfs.ns:
          NS fragment used in conjunction with
      	tb-elab-in-elab-topology "withfs"
          to setup inner-elab with fs node.
      
      elabinelab.ns:
          The hard work on the boss side.  Recognize seperate-fs config and handle
          running of rc.mkelab on that node.  fs setup happens before ops setup.
      
      rc.mkelab:
          The hard work on the client side.  Recognize FsNode setup as well as
          differentiate ops+fs from ops setup.
      
      Related stuff either not part of the repo or checked in previously:
          emulab-fs package
      c53d5827
  2. 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
  3. 28 Jul, 2005 1 commit
  4. 06 May, 2005 4 commits
  5. 05 May, 2005 1 commit
  6. 04 May, 2005 1 commit
  7. 28 Apr, 2005 1 commit
  8. 29 Mar, 2005 2 commits
  9. 27 Jan, 2005 1 commit
  10. 03 Jan, 2005 1 commit
  11. 03 Dec, 2004 1 commit
    • Leigh B. Stoller's avatar
      Two small changes: · edf6838c
      Leigh B. Stoller authored
      * Do not fetch the cisco MIBS inside an ElabInElab; takes too long and
        they are not needed.
      
      * Add some timestamp output to "Phase" so I can see where the time is
        going. I'll pull this out later.
      edf6838c
  12. 29 Nov, 2004 1 commit
  13. 05 Nov, 2004 1 commit
  14. 01 Nov, 2004 1 commit
  15. 27 Oct, 2004 2 commits
  16. 26 Oct, 2004 1 commit
    • Leigh B. Stoller's avatar
      Pump up dhcpd_makeconf ... · 29b8c214
      Leigh B. Stoller authored
      * Add -i option to install the new dhcpd file into place, backing up
        the old version. Does not restart dhcpd though; that is left to
        someone else at the moment. May change later. Without -i, works as
        before, writing the new config file to stdout. Of course, must use
        the standard locking protocol to serialize when using -i, lest we
        end up with a garbled dhcpd.conf file.
      
      * Add -t option to specify the template file. Changed default
        behaviour so that without any args, uses the template file in
        /usr/local/etc. Together with -i option, this moves the two
        hardwired paths to a single place (script).
      
      * Changed how utiils/newnode script calls dhcpd_makeconf (call with
        just -i option to let dhcpd_makeconf handle all that icky stuff).
      
      * Changed how install/boss-install script calls dhcpd_makeconf (call with
        just -i option to let dhcpd_makeconf handle all that icky stuff).
      
      * Also change boss-install to use install target in dhcpd directory,
        to install the template file.
      29b8c214
  17. 25 Oct, 2004 1 commit
  18. 08 Oct, 2004 1 commit
    • Leigh B. Stoller's avatar
      More automation for ElabInElab. · a1f5344f
      Leigh B. Stoller authored
      * Add password option to pass in initial elabman password on the
        command line.
      
      * Call Rob's firstuser script with password to set up the initial
        account and project.
      
      * Startup elvind and apache.
      
      * Run initial named configuration and install named files, then start
        up named.
      
      * Create the initial experiments, now that all the above daemons are
        running.
      
      The basic idea here is that you no longer need to reboot ops or boss
      when installing Emulab. Run the ops install, then run the boss
      install. Then reboot (ops first of course). This should make the
      initial setup synchronization slightly easier, I hope ...
      a1f5344f
  19. 05 Oct, 2004 1 commit
    • Leigh B. Stoller's avatar
      * Create /etc/hosts on boss and make sure that names resolve. · 91e96bab
      Leigh B. Stoller authored
      * Reorder and reorg slightly the ports install section to deal with
        the case where the ports are already installed from packages before
        calling boss-install.
      
      * Install initial self signed apache cert/key from the ssl directory
        so that apache will run right away. Also make sure that startup file
        in /usr/local/etc/rc.d is renamed so it runs at bootup.
      
      * Build and install testbed tree from boss-install. This is nice for
        inner elab, but might not be such a good idea for real installations
        cause it goes away for a really long time, and cause the output from
        the make is lost. Rob, suggestions? Maybe just redirect the output
        and tell the user about it?
      
      * Install newly created dhcpd.conf template file, and generate a new
        dhcpd.conf file from it. Also, touch /var/db/dhcpd.leases or else
        dhcpd breaks. How stupid is that?
      91e96bab
  20. 01 Oct, 2004 1 commit
  21. 30 Sep, 2004 3 commits
  22. 28 Sep, 2004 2 commits
  23. 27 Sep, 2004 1 commit
    • Leigh B. Stoller's avatar
      Some minor changes: · 77cb5a5b
      Leigh B. Stoller authored
      * Change how we get the root key over to boss during initial installation.
        Instead of breaking out and having the user do it by hand, we have a
        default keypair in the repo that is installed long enough to allow boss
        to ssh over to ops and install the newly generated keypair. The keypair
        is in the repo cause it won't ever be used anyplace else. Just to be
        safe, I prefix it with a from="boss.emulab.net" option when ops-install
        sticks it into root's authkeys file.
      
      * Fix a couple of bugs in the root key ssh. @ needs to be escaped in perl,
        and must use BatchMode=yes option or else the check to see of the root
        key was copied just hangs!
      
      * Add initialization of mysql user and group since the pkg does not do that
        (the port does though).
      77cb5a5b
  24. 24 Sep, 2004 2 commits
  25. 21 Sep, 2004 2 commits
  26. 17 Sep, 2004 2 commits
  27. 16 Sep, 2004 1 commit
  28. 14 Sep, 2004 1 commit
  29. 01 Sep, 2004 1 commit
    • Leigh B. Stoller's avatar
      SSL version of the XMLRPC server. · a9c1045e
      Leigh B. Stoller authored
      * SSL based server (sslxmlrpc_server.py) that wraps the existing Python
        classes (what we export via the existing ssh XMLRPC server). I also have a
        demo client that is analogous the ssh demo client (sslxmlrpc_client.py).
        This client looks for an ssl cert in the user's .ssl directory, or you can
        specify one on the command line. The demo client is installed on ops, and
        is in the downloads directory with the rest of the xmlrpc stuff we export
        to users. The server runs as root, forking a child for each connection and
        logs connections to /usr/testbed/log/sslxmlrpc.log via syslog.
      
      * New script (mkusercert) generates SSL certs for users. Two modes of
        operation; when called from the account creation path, generates a
        unencrypted private key and certificate for use on Emulab nodes (this is
        analagous to the unencrypted SSH key we generate for users). The other mode
        of operation is used to generate an encrypted private key so that the user
        can drag a certificate to their home/desktop machine.
      
      * New webpage (gensslcert.php3) linked in from the My Emulab page that
        allows users to create a certificate. The user is prompted for a pass
        phrase to encrypt the private key, as well as the user's current Emulab
        login password. mkusercert is called to generate the certificate, and the
        result is stored in the user's ~/.ssl directory, and spit back to the user
        as a text file that can be downloaded and placed in the users homedir on
        their local machine.
      
      * The server needs to associate a certificate with a user so that it can
        flip to that user in the child after it forks. To do that, I have stored
        the uid of the user in the certificate. When a connection comes in, I grab
        the uid out of the certificate and check it against the DB. If there is a
        match (see below) the child does the usual setgid,setgroups,setuid to the
        user, instantiates the Emulab server class, and dispatches the method. At
        the moment, only one request per connection is dispatched. I'm not sure
        how to do a persistant connection on the SSL path, but probably not a big
        deal right now.
      
      * New DB table user_sslcerts that stores the PEM formatted certificates and
        private keys, as well as the serial number of the certificate, for each
        user. I also mark if the private key is encrypted or not, although not
        making any use of this data. At the moment, each user is allowed to get
        one unencrypted cert/key pair and one encrypted cert/key pair. No real
        reason except that I do not want to spend too much time on this until we
        see how/if it gets used. Anyway, the serial number is used as a crude form
        of certificate revocation. When the connection is made, I suck the serial
        number and uid out of the certificate, and look for a match in the table.
        If cert serial number does not match, the connection is rejected. In other
        words, revoking a certificate just means removing its entry from the DB
        for that user. I could also compare the certificate itself, but I am not
        sure what purpose that would serve since that is what the SSL handshake is
        supposed to take of, right?
      
      * Updated the documentation for the XMLRPC server to mention the existence
        of the SSL server and client, with a pointer into the downloads directory
        where users can pick up the client.
      a9c1045e