| commit | 5b9ee71ac132b355a8875d8d15f5ec3184ece43f | [log] [tgz] |
|---|---|---|
| author | Mathieu Binette <mbinette@google.com> | Thu Apr 04 16:52:30 2019 |
| committer | Mathieu Binette <mbinette@google.com> | Thu Apr 04 17:03:00 2019 |
| tree | ce3e14c2c9d2c81b8a5db0d502b52b5e0f2d7b01 | |
| parent | 61d11dbf086cebd06c31d034b938ba97a9c10ac9 [diff] |
Refactoring of NestedVM-specific RunCommand code.
Main changes:
1- `RunCommand` was confusing and sometimes used incorrectly.
Renamed to RunLocalCommand and added a new RunCommand that runs a command
on the current CEL instance (locally or on a nestedVM).
1B- Removed near-duplicate code: RunConfigCommands, `cmd ver`, ...
2- RunConfigCommand always runs locally.
It means we don't support nested VMs onhost configs for free, and the onhost
code has to handle it separately (like it did in domain_join).
The onhost normally code shouldn't have to care about if the current instance
is a nested VM or not (except in some specific scenarios).
Added NestedVM support in RunConfigCommand to get free nested VM support
for onhost configs.
* We don't support server configs on Win10/7, but we do get some configs for
free without having to branch all of our onhost code. For example,
windows_registry.go didn't work before and now works with Win10.
2B- Added Win10 to our MachineRegistry test. Failed before, succeeds now.
3- GetSupportingFilePath always returns a local supporting filepath, but most
callers want the path to the supporting file on the CEL instance.
This leads to workingDirectoryOnNestedVM being used all over the place.
Renamed to GetLocalSupportingFilePath and added GetSupportingFilePath that
handles the abstraction.
4- Fixed bug in UploadFileToNestedVM when destDir != workingDirectoryNestedVM
Can happen in Commander (`cel_ctl run`).
5- Fixed escaping bugs with sshRunCommand affecting some scripts intermittently
(e.g. depending on admin passwords), as well as some Commander commands.
Change-Id: I8bb54aecf9be1cb39a06887dec0e7ad57053dbd9
Reviewed-on: https://chromium-review.googlesource.com/c/enterprise/cel/+/1547994
Reviewed-by: Fei Ling <feiling@chromium.org>
Chrome Enterprise Lab is an inaccurately named set of tools for building enterprise labs quickly and easily. The labs so built can be used for system level end-to-end testing of Google Chrome/Chromium.
Have a peek at the Design document.
Also have a peek at the Code of Conduct.
Most of the code is in Go. See Guide to code to get a head start on the code in this repository.
Go: Download Go from the Go download page. This project requires Go 1.9.4 or later. The build will fail with prior versions.
Depot Tools: Used for managing the checkout and the contributor workflow.
Protocol Buffers Compiler: Protocol buffers are used extensively for wranging all the data that needs to be shuttled around. Can be installed automatically via ./build.py deps --install.
Dep : Used for Go depedency management. This can be installed automatically by running ./build.py deps --install from the root of the source tree.
Go support for Protocol Buffers : This can be installed automatically by running ./build.py deps --install from the root of the source tree.
absl-py: This Python package is used by tests. Install it by running pip install absl-py.
There are two ways to get the source. One is to use managed deps, and the other is to use plain go get. The latter workflow doesn't quite work yet due to this repository not being integrated with go.chromium.org. So this page only mentions the managed dependency workflow.
Clone this repository:
Assumes that $GOPATH is a single path and not a : delimited list.
mkdir -p ${GOPATH}/src/chromium.googlesource.com/enterprise cd ${GOPATH}/src/chromium.googlesource.com/enterprise git clone https://chromium.googlesource.com/enterprise/cel cd cel
Get the dependencies:
python build.py deps --install
Use the build script:
python build.py build
Also make sure the tests pass.
python build.py test
See CONTRIBUTING.