Updates based on mail from Alex
authorSam Hartman <hartmans@debian.org>
Wed, 15 May 2013 11:51:04 +0000 (07:51 -0400)
committerSam Hartman <hartmans@debian.org>
Wed, 15 May 2013 11:51:04 +0000 (07:51 -0400)
building.mdwn
prepare.mdwn

index 462b8f6..7c9ac47 100644 (file)
@@ -13,22 +13,20 @@ First, make sure you have the following dependencies installed:
 1. log4cpp or log4shib
 1. [libevent](http://www.monkey.org/~provos/libevent/) at least
 version 2.0
 1. log4cpp or log4shib
 1. [libevent](http://www.monkey.org/~provos/libevent/) at least
 version 2.0
+1. Sqlite version 3
+1. Libtalloc
+1. A variety of Gnome and GTK components; the UI package in the source tree will complain if components are missing
+
 
 On a Debian or Ubuntu system you can get a lot of these dependencies
 with:
 
     aptitude install libxml-security-c-dev libxerces-c-dev \
       libcurl4-openssl-dev liblog4cpp5-dev autotools-dev doxygen libtool \
 
 On a Debian or Ubuntu system you can get a lot of these dependencies
 with:
 
     aptitude install libxml-security-c-dev libxerces-c-dev \
       libcurl4-openssl-dev liblog4cpp5-dev autotools-dev doxygen libtool \
-      libconfuse-dev libfreeradius-dev
-
-    aptitude install -t unstable libkrb5-dev
+      libconfuse-dev autoconf automake python \
+      libsqlite3-dev libtalloc-dev fakeroot libkrb5-dev libevent-dev
 
 
-    aptitude install -t experimental libevent-dev
 
 
-A sufficiently new version of libevent is in the libevent-dev package
-in Debian experimental. The libkrb5-dev in Debian experimental is also
-sufficiently new. [Sam Hartman](http://www.launchpad.net/~hartmans)
-maintains sufficiently new krb5 for Ubuntu.
 Ensure that libgss-dev is not installed as the headers are conflicting 
 with the headers from libkrb5-dev.
 
 Ensure that libgss-dev is not installed as the headers are conflicting 
 with the headers from libkrb5-dev.
 
@@ -37,12 +35,7 @@ Follow the
 instructions for checking out a copy of Moonshot At this writing, the
 following should be sufficient: 
 
 instructions for checking out a copy of Moonshot At this writing, the
 following should be sufficient: 
 
-    git clone http://www.project-moonshot.org/git/moonshot.git
-    cd moonshot
-    git submodule init
-    git submodule update
-
-
+    git clone --recursive http://www.project-moonshot.org/git/moonshot.git
 
 Create some directory that you have permission to write to. We'll
 assume this is /usr/local/moonshot. Run
 
 Create some directory that you have permission to write to. We'll
 assume this is /usr/local/moonshot. Run
index eb92ff4..312c857 100644 (file)
@@ -5,44 +5,16 @@ This set of instructions assumes you are using system Kerberos libraries; some t
 
 First, look at the mech file in the mech_eap directory of the source tree. Copy this file to /etc/gss/mech (or on Debian/Ubuntu systems /usr/etc/gss/mech). The Debian path is a bug that will be fixed; this page will be updated after.
 
 
 First, look at the mech file in the mech_eap directory of the source tree. Copy this file to /etc/gss/mech (or on Debian/Ubuntu systems /usr/etc/gss/mech). The Debian path is a bug that will be fixed; this page will be updated after.
 
-Then, create a symlink from /usr/lib/gss/mech_eap.so to the installed mech_eap.so. Are you getting the feeling you're running down some untested code paths here yet?
-
-On Debian systems if you are using the system freeradius libraries make sure /usr/lib/freeradius is in your default linker search path. Perhaps edit /etc/ld.so.conf and run ldconfig. Yes, that too is a bug. If you are not using system freeradius libraries you probably have to do something similar.
-
-Create a valid freeradius dictionary in $prefix/etc/radb/dictionary. This may be a bug as well.
-
-# Configuring Kerberos
-
-Configure Kerberos, you ask? But I'm not using Kerberos!
-True, but the Kerberos library is kind of self-centered at the moment and doesn't believe anyone would ever want to not use Kerberos.
-So, it requires that servers be able to set up Kerberos even if they never use it.
-Please see also a bug.
-So you want something like
-
-Contents of /etc/krb5.conf:
-
-    [libdefaults]
-        default_realm = YOUR_DOMAIN_ALL_CAPS
-
-Then run ktutil
-
-    addprinc --password -p host/hostname.your_domain@YOUR_DOMAIN_ALL_CAPS -k 1 -e aes256-cts
-
-Enter a password of your choice
-
-   wkt /etc/krb5.keytab
-    quit
-
-Then <code>chmod a+r /etc/krb5.keytab</code>. Note that would be a very bad thing to do if you actually were using Kerberos. It may still be a bad thing to do if you have services enabled that can potentially use Kerberos.
+Then, create a symlink from /usr/lib/gss/mech_eap.so to the installed mech_eap.so. Are you getting the feeling you're running down some untested code paths here yet? Your system may use /usr/lib64/gss, or /usr/lib/architecture-and-os/gss instead.
 
 # Configuring libradsec
 
         cat > $prefix/etc/radsec.conf << EOF
 
 # Configuring libradsec
 
         cat > $prefix/etc/radsec.conf << EOF
-        config gss-eap {
+        realm gss-eap {
             type = "UDP"
             server {
                 hostname = "127.0.0.1"
             type = "UDP"
             server {
                 hostname = "127.0.0.1"
-                service = "1820"
+                service = "1812"
                 secret = "$secret"
             }
         }
                 secret = "$secret"
             }
         }