| |
| Entd Development/Test Cycle |
| =========================== |
| |
| Most entd features and fixes can be developed and unit tested entirely in the |
| source directory of entd while in your chroot. Entd can be built for your |
| target platform using only the scons file (no need for emerge or ebuild), and |
| can be launched using scripts/run_32bit.sh, or the run_tests.sh script from |
| Entd. |
| |
| To build an x86 version of entd, run... |
| |
| $ cd platform/entd |
| $ scons CHOST=i686-pc-linux-gnu SYSROOT=/build/x86-generic/ |
| |
| This will create a platform/entd/out/i686-pc-linux-gnu/ directory and place |
| the target executable there. |
| |
| Then, to launch entd... |
| |
| $ ../../scripts/run_32bit.sh ./out/i686-pc-linux-gnu/entd |
| [0721/093224:INFO:main.cc(130)] Starting entd |
| ... |
| [0721/093224:ERROR:entd.cc(471)] Can't determine hostname from username: |
| [0721/093224:INFO:main.cc(208)] Exiting entd with code: 1 |
| |
| Entd takes a number of command line arguments. The error message we just |
| got is a sign that we forgot --username. In order to pass arguments through |
| the run_32bit.sh script, we need to separate the script's arguments from |
| entd's, using --, as in... |
| |
| $ ../../scripts/run_32bit.sh ./out/i686-pc-linux-gnu/entd -- \ |
| --username=user@example.com |
| [0721/094034:INFO:main.cc(130)] Starting entd |
| ... |
| [0721/094034:ERROR:entd.cc(531)] No policy file. |
| [0721/094034:INFO:main.cc(208)] Exiting entd with code: 1 |
| |
| Here we've failed to start because we haven't specified a policy file, we can |
| do that using --policy. Before that, we'll introduce a shell variable to make |
| the command lines slightly shorter... |
| |
| $ ENTD="../../scripts/run_32bit.sh ./out/i686-pc-linux-gnu/entd --" |
| $ $ENTD --username=user@example.com --policy=test_data/hello-world.js |
| |
| This time you'll notice that entd doesn't exit on its own. This is an |
| unfortunate side effect of the way it catches signals. It's not an issue |
| in production, where we expect entd to keep running, but can be troublesome |
| for testing. You can add the --allow-dirty-exit, which prevents entd from |
| registering to handle signal events, and therefore allows it to exit when |
| the policy execution completes. Press Ctrl-C to terminate entd, and then |
| run... |
| |
| $ $ENTD --username=user@example.com --policy=test_data/hello-world.js \ |
| --allow-dirty-exit |
| [0721/094725:INFO:main.cc(130)] Starting entd |
| hello world |
| [0721/094725:INFO:entd.cc(540)] Policy loaded. |
| [0721/094725:INFO:main.cc(208)] Exiting entd with code: 0 |
| |
| And now you've had your first successful run of the Enterprise Daemon. Go you. |
| |
| For now, entd command line arguments are only documented in source. You'll |
| have to read through the top of main.cc for usage information, or read through |
| the run_tests.sh script for examples. |
| |
| The run_tests.sh script runs the entd unit tests, as you might have guessed. |
| It's a little janky, but it gets the job done. It's simple to start, and looks |
| something like this... |
| |
| $ ./run_tests.sh |
| PASS: hello-world.js |
| PASS: bad-onload.js |
| ... |
| PASS: simple-shutdown.js |
| PASS: simple-callback.js |
| |
| Tests completed: 28 |
| TESTS FAILED: 0 |
| |
| Many of the unit tests require you to have PKCS11 set up in your development |
| environment. See the README.pkcs11 file in this directory for details on how |
| to get that running. |
| |
| You should make sure to write new unit tests for any new functionality, |
| regression tests for bug fixes, and ensure that all tests pass before submitting |
| a CL for review. |
| |
| |