InSpec: "Cannot load <profile> since it is not listed as a dependency" when dependency is defined - inspec

In InSpec 1.9.0 I defined the following profile with dependency, including all controls from the dependent profile.
However, when executing I get the error indicating the profile "is not listed as dependency"
What am I missing?
inspec.yml:
name: my-profile
version: 0.0.1
supports:
- os-family: unix
depends:
- name: ssh-baseline
url: https://github.com/dev-sec/ssh-baseline/archive/master.zip
controls/include_ssh_baseline.rb:
include_controls 'ssh-baseline'
Command:
inspec exec my-profile -t ssh://user#host.domain
The result of executing the profile:
Cannot load ssh-baseline since it is not listed as a dependency
of my-profile.
Dependencies available from this context are:
(two empty lines)
I don't see a syntax error. It's almost copy-paste example from InSpec Profiles page.
The following dependency definition (git instead of url) also caused the same error message as above:
depends:
- name: ssh-baseline
git: https://github.com/dev-sec/ssh-baseline.git

inspec.lock file is created on the first profile execution and contains a reference to the dependencies. If you build your profile incrementally you might end up with an inspec.yml file containing no dependencies (from the first run):
---
lockfile_version: 1
depends: []
You need to delete the file if you want changes to the inspec.yml to be reflected or run the following inside the profile directory:
inspec vendor --overwrite
See Vendoring dependencies (it doesn't mention --overwrite, but it immediately throws an error if it's not present):
When you execute a local profile, the inspec.yml file will be read in order to source any profile dependencies. It will then cache the dependencies locally and generate an inspec.lock file. If you add or update dependencies in inspec.yml, please refresh the lock file by either:
running inspec vendor inside the profile directory; or
deleting inspec.lock before running inspec exec

I just created it a profile based on your post and it works without any issues. I used inspec 1.9.0. Just to be sure, can you try inspec exec ./my-profile -t ssh://user#host.domain?

Related

Getting errors while trying to build istio source on mac

I'm a newbie in Istio and I’m trying to build the Istio source locally in mac but somehow when I run "make build" I get the following errors.
...
Downloading envoy: https://storage.googleapis.com/istio-build/proxy/envoy-alpha-74393cf764c167b545f32eb895314e624186e5b6.tar.gz to
real 0m5.288s
user 0m0.707s
sys 0m0.685s
cp: cannot create regular file '': No such file or directory
Unexpected failure
make[1]: *** [Makefile.core.mk:230: /work/out/darwin_amd64/istio_is_init] Error 1
...
These are the following env variables that I have set.
export HUB="docker.io/shriramsharma"
export TAG="shriramsharma"
export GOOS=darwin
export USE_LOCAL_PROXY=1
export BUILD_WITH_CONTAINER=1
Is there something I’m missing? any help would be appreciated
Version: I ran make build on the master branch of the source. I did not checkout any release version tag.
Docs: I followed the steps in the docs here. https://github.com/istio/istio/wiki/Preparing-for-Development-Mac

How to reference yaml variable file present in github in robot framework test case file in github

I ran Robot framework test cases(present in github) through azure pipeline. Test cases executed fine. Next I modified robot framework test case file to import yaml variable file (variable yaml file also present in same github repo folder) which has variables to be used by test cases file.
yaml variable file looks like this
login:
url: xxx.com
email: abc#y.com
password: xyz
And my test cases file look like this
*** Settings ***
Library SeleniumLibrary
Variables variablesfile.yaml
*** Test Cases ***
Dev_TC01_AddProcess
Open Browser ${login.url} chrome
Input Text id=email ${login.email}
Input Password id=password ${login.password}
And my yaml pipeline to trigger test scenarios looks like this
- script: |
pip install pytest pytest-azurepipelines
pytest
robot --pythonpath . -x outputxunit.xml TestScenarios.robot
displayName: 'Run Robot Scripts'
but on running the pipeline I get error, because test scenarios file is unable to reference variablesfile.yaml. got error message - Resolving variable '${login.url}' failed:
Can you please suggest how to reference variable file
Above error seems to be caused by the variables yaml file not being found.
If you defined Variables file in the Settings section like what you defined in above example. You should put the variables yaml files in the same directory of the test robot file TestScenarios.robot.
If the variables files are not under the same directory. You can define the correct relative path in the Settings section like below example: See here.
Variables ../data/variables.yaml
Note:
Using YAML files with Robot Framework requires PyYAML module to be installed. If you have pip_ installed, you can install it simply by running pip install pyyaml.
Variables file is in the same directory of TestScenarios.robot. I also tried entering the full path still it didnt work. Finally i got a solution, I need to run pip install pyyaml script then it worked

How to build Conda env on Mac using Windows yml file?

I'm creating Conda create environment from yml I generated on Windows' Miniconda install. I need to create same environment on OS X. Following the advise found here on SO I used the --no-builds option.
Also, the names of some packages under section ResolvePackageNotFound are clearly (many if not all) specific to Windows:
- m2w64-gmp=6.1.0
- m2w64-gcc-libs-core=5.3.0
- m2w64-gcc-libs=5.3.0
- vc=14.1
- vs2015_runtime=15.5.2
- msys2-conda-epoch=20160418
- menuinst=1.4.14
- icc_rt=2019.0.0
- m2w64-libwinpthread-git=5.0.0.4634.697f757
- pywinpty=0.5.5
- wincertstore=0.2
- m2w64-gcc-libgfortran=5.3.0
- win_inet_pton=1.1.0
- winpty=0.4.3
I removed all of these from the yml file. Even then it's stalled at the following screen:
(base) MacBook-Air:Anaconda.d xtian$ conda env create -f 32b-qb-2019-10-05.yml
Collecting package metadata (repodata.json): done
Solving environment: \
Found conflicts! Looking for incompatible packages.
This can take several minutes. Press CTRL-C to abor|
Examining openssl: 10%|█████████▍ | 29/279 [00:00<00:00, 3729.87it- ]
Comparing specs that have this dependency: 16%|██████████▉ | 16/101 [05:53<31:19, 22.11s/it]
Finding shortest conflict path for openssl[version='>=1.0.2p,<1.0.3a']: 38%|███████████████▊ | 6/16 [02:39<06:23, 38.32s/it]
This process is progressing at an astonishingly slow pace, and hasn't got past openssl ... 29/279. Should I wait and trust Conda can figure this all out?
Or,
Do I need another strategy--
I'm wondering if I can't remove the offending packages, each in turn, and create a series of yml files to install in order using, $ conda env update --prefix ./env --file environment.yml --prune, because whatever finally works here I know I'm going to need to use it on another machine so I can share the project env with a colleague.
Any other suggestions?
Short answer: Try deleting the packages that your system is getting stuck on from the .yml file. i.e., remove "openssl" from .yml file.
I have been running into the same issue trying to install a .yml file created in a Windows system to a Mac system. I basically followed the same procedure you did:
-Created yml file using the --no-builds option.
-Attempted to create environment on Mac system and had several windows specific packages left under ResolvePackageNotFound section (listed below)
m2w64-libwinpthread-git=5.0.0.4634.697f757
pyreadline=2.1
pywinpty=0.5.5
m2w64-gcc-libgfortran=5.3.0
vc=14
m2w64-gcc-libs-core=5.3.0
m2w64-gmp=6.1.0
wincertstore=0.2
icc_rt=2019.0.0
m2w64-gcc-libs=5.3.0
vs2015_runtime=14.15.26706
winpty=0.4.3
msys2-conda-epoch=20160418
-Deleted those from the yml file
-Attempted to create environment from updated yml file and received the following conflicts:
- Found conflicts! Looking for incompatible packages.
My system also got stuck trying to solve the "openssl" conflict along with a "_tflow_select". I ended up deleting those and was able to create my environment and run the code without too much trouble.

Deploying .NET Core Application with Windows Compatibility Pack

I'm busy deploying a .NET Core 2.1 application into our testing environment, but I'm getting the following error.
Error:
An assembly specified in the application dependencies manifest (MyApp.deps.json) was not found:
package: 'System.Diagnostics.EventLog', version: '4.5.0'
path: 'runtimes/win/lib/netcoreapp2.1/System.Diagnostics.EventLog.dll'
We are using the Windows Compatibility Pack to access the Event Log.
I have the following item in the dependency Json file:
"System.Diagnostics.EventLog/4.5.0": {
"dependencies": {
"Microsoft.Win32.Registry": "4.5.0",
"System.Security.Permissions": "4.5.0",
"System.Security.Principal.Windows": "4.5.0",
"System.Threading.AccessControl": "4.5.0"
},
"runtime": {
"lib/netstandard2.0/System.Diagnostics.EventLog.dll": {
"assemblyVersion": "4.0.0.0",
"fileVersion": "4.6.26515.6"
}
},
"runtimeTargets": {
"runtimes/win/lib/netcoreapp2.0/System.Diagnostics.EventLog.dll": {
"rid": "win",
"assetType": "runtime",
"assemblyVersion": "4.0.0.0",
"fileVersion": "4.6.26515.6"
}
}
}
Please advise how one should deploy these dependencies. Also, what is the root folder to this relative path runtimes/win/lib/netcoreapp2.0?
We actually found a solution for our scenario:
- Our situation was that we tried to run a netcoreapp based test project on our test agent
- dotnet test on the project file worked
- dotnet vstest sometimes worked on the project output directory (we are not sure why and on which setup)
- dotnet vstest did run into the above error when run into an other directory & downloaded from CI
- dotnet vstest did run into an AssemblyNotFoundException on the test agent (which didn't make any sense for us)
The solution was to use dotnet publish for our test project and use the "self-contained" output to run on the test agent. dotnet publish copied the required runtimes/win/lib/netcoreappX.X/*.dll files into the publish output directory.
After a lot of testing, the key issue seems to be the "RuntimeIdentifiers". There is a visible option for this when you publish, but in order to use it when just building you need to add a couple of tags to your .csproj file.
The first is:
<RuntimeIdentifier>win-x86</RuntimeIdentifier>
This will cause NuGet to retrieve the correct dlls (change the value depending on your needs). For me I was compiling to platform x86. I don't know what NuGet was getting by default, but whatever it was had different file sizes for the same files.
You also should then add this tag:
<SelfContained>false</SelfContained>
or else your build will default to copying the entire framework.
Also note that using the RuntimeIdentifier tag will cause your default output folder to include the value you specified. For example my subfolder became:
Project\bin\x86\Debug\netcoreapp3.1\win-86\
For publishing you should be able to do something similar; the problem will be to match your RuntimeIdentifier to your platform. You shouldn't need to specify SelfContained unless you specifically need to.

How to determine dependencies of recipes in yocto?

I want to add gedit to the the image. But i am not able to find the dependencies of gedit package. How to find the dependencies (DEPENDS) in yocto.
You can use the following command which opens up a Dependency explorer that displays dependencies on the packages:
bitbake -g recipe-name -u depexp
or bitbake -g gedit -u depexp, in your case.
On pyro and later use:
bitbake -g recipe-name -u taskexp
Note: this command needs python-gtk2 installed.
You can also use Toaster, which is a web UI that collects information about what you build, including dependencies. This video shows the dependency information provided:
https://www.youtube.com/watch?v=x-6dx4huNnw
Details on how to set up and use Toaster at
https://www.yoctoproject.org/docs/latest/toaster-manual/toaster-manual.html
The list of packages installed in your image is stored in the manifest file (besides of build history which is already mentioned).
Content of the manifest file looks like:
alsa-conf cortexa7hf-neon-vfpv4 1.1.2-r0.1
alsa-conf-base cortexa7hf-neon-vfpv4 1.1.2-r0.1
alsa-lib cortexa7hf-neon-vfpv4 1.1.2-r0.1
alsa-states cortexa7hf-neon-vfpv4 0.2.0-r5.1
alsa-utils-alsactl cortexa7hf-neon-vfpv4 1.1.2-r0.5
alsa-utils-alsamixer cortexa7hf-neon-vfpv4 1.1.2-r0.5
...
The list consists of the package name, architecture and a version.
That manifest is located in the deploy directory (i.e. deploy/images/${MACHINE}/). Here as an example of the directory listing (there are target images and the manifest file)
example-image-genericx86.ext3
example-image-genericx86.manifest
example-image-genericx86.tar.bz2