This repository is part of the Triton Data Center project. For contribution guidelines, issues, and general documentation, visit the main Triton project page.
UFDS is the "unified foundational directory service" built for Triton over ldapjs and moray, and is used to track accounts, credentials, and more. It is a superset of functionality offered by previous Triton versions employing CAPI (there is a backwards compatible "shim" that offers the same API as CAPI did in SDC 6.5).
git clone [email protected]:TritonDataCenter/sdc-ufds.git
cd sdc-ufds
git submodule update --init
make all
node main.js -f ./etc/config.coal.json -d 2 2>&1 | bunyan
This assumes several things:
- You've got a moray instance running exactly how it's specified on the
config file
etc/config.coal.json. - Your node version is greater than 0.8.
- You want to see debug output. If you don't, remove the
-d 2, but it's strongly recommended while hacking. - You do have bunyan module installed globally. Given the
make allcommand should also install it locally, you could also replace that with./node_modules/.bin/bunyan.
Normal tap-formatted output:
make test
Faucet enhanced output:
npm run test
View generated coverage information
npm run report
Of course, if you run make test all these tasks will run.
Schema for UFDS is built on a custom framework where you extend a
Validator class, and simply model the attributes you want, whether
they're required or optional, and the number of values to allow. This
means to add new schema types into UFDS, you have to write (minimal)
code. Take a look at ./schema to get a feel for what this looks
like. It's really not rocket science.
The schema framework automatically runs on add/modify/modifyDN, and UFDS "discovers" all schema in that directory, so all you need to do to get a new type in the system is drop a file in there.
In terms of the paradigm, you describe your required attributes, and the number of values each can have, and then decide whether or not you want the type to be strict. Strict set to true means that only the attributes described in your schema will be allowed, and you can then use the optional block to describe optional attributes. If strict is false, then optional is pretty much irrelevant, as anything goes (required attributes however, must be present). The default for strictness is false.