| commit | 0b08d596d3939d4c9148aec20ebb824647af1ee4 | [log] [tgz] |
|---|---|---|
| author | Bogdan Caprita <caprita@google.com> | Fri Apr 08 17:00:28 2016 -0700 |
| committer | Bogdan Caprita <caprita@google.com> | Mon Apr 11 17:09:22 2016 +0000 |
| tree | b052a558788570575d94c45eeab75fea34278a7c | |
| parent | a5ed1911a8930292d8f778f1e0f7e1974ec53c45 [diff] |
Turn on loading on-disk credentials using agent This change 'flips the switch' to start using the agent (or fallback to loading the credentials locally under exclusive lock) whenever credentials are specified with V23_CREDENTIALS or --v23.credentials. Specifically, rt/security.go now uses agentlib.LoadPrincipal. Some adjustment is required in tests, where we don't want to start an agent (even if v23agentd is in the PATH), but we still want the exclusive local loading feature. A new environment variable V23_CREDENTIALS_NO_AGENT disables spawning an agent in agentlib.LoadPrincipal. This environment variable is set in tests that use test.V23Init or v23test.Shell, and should propagate to subprocesses started by tests. With this CL, the confusing behavior whereby a new principal would implictly get created if the credentials directory specified with V23_CREDENTIALS or --v23.credentials didn't contain one, is gone: such cases are now treated as errors when trying to load the principal. A few places (under device manager) that relied on the old behavior have been updated to explicitly create the principals they need. Also in device manager, the PATH is now propagated s.t. child processes have access to the 'ps' command used in the locking code. Note, this will no longer be needed after v.io/c/21248 (access to 'ps' becomes a nice-to-have but not required in order to lock or verify a lock). A note on platforms other than Linux and Darwin: we rely on the presence of a valid v23agentd in the PATH when loading the principal. If that doesn't exist, agentlib.LoadPrincipal falls back onto loading the principal locally under lock. This seems like the right thing to do on any platform (until proven otherwise :-)). The locking code should also become robust in the face of missing 'ps' with v.io/c/21248. MultiPart: 2/2 Change-Id: I5856d6a0f104d7cb413eae513c2fd8acaa1e7ea3
This repository contains the source code for generating the static assets for the Vanadium website.
browser - Client-side JS that executes when users visit the websitebuild - Output location for make buildcontent - Markdown content; gets converted to HTML by haikuhelpers.js - JS used by haiku when rendering Markdown filesnode_modules - Disposable directory created by npm installpackage.json - Tells npm install what to installpublic - Static assets, copied directly into the build directorystylesheets - LESS stylesheets, compiled into CSS for the websitetemplates - Mustache templates used by haiku for layouts and partialstools - Tools involved in generating the site's static assetsInstall Vanadium per the installation instructions on the website. Also, install the Node.js profile using jiri profile install v23:nodejs.
You can make and view changes locally by running a development server:
make serve
This command will print out a URL to visit in your browser. It will take a few minutes to run the first time around, but subsequent invocations will be fast.
By default, the running server will not reflect subsequent changes to the website content, since it's just serving the assets in the build directory. Running make build will cause the server to see the new content. Better yet, use the following command to automatically rebuild the assets whenever something changes:
make watch
This command requires the entr program, which can be installed on Debian/Ubuntu using apt-get install entr, and on OS X using brew install entr.
Add or modify Markdown-formatted files in the content directory.
The haiku tool provides some extra flexibility on top of standard Markdown by processing Mustache template variables. For example:
= yaml =
title: My Creative Title
author: Alice
= yaml =
# {{ page.title }}
Author: {{ page.author }}
A common editing workflow is to run make watch, edit Markdown files in a text editor, and refresh the browser to see changes. If you prefer a WYSIWYG editing experience, there are a number of options, e.g.:
For new content, it's common to do initial drafting and editing in Google Docs, and to switch to Markdown at publication time.
The make build task generates public/css/bundle.css and public/js/bundle.js from the files in stylesheets and browser respectively. To modify the website CSS or JS, edit those files, then rebuild the site (or use make watch to have your changes trigger rebuild).
Jenkins automatically deploys to production on every successful build of vanadium-website-site target.