-
Notifications
You must be signed in to change notification settings - Fork 13
ROX-13770: Introduce local Node Scanner #1164
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Images are ready for the commit at 1b12dd0. To use the images, use the tag |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, but I think we should mention the content sets in the readme as it is an important element of this all
tools/local-nodescanner/Dockerfile
Outdated
|
||
COPY ./bin/local-nodescanner /local-nodescanner | ||
|
||
ENTRYPOINT [ "/local-nodescanner" ] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could add that newline at the end of file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
tools/local-nodescanner/README.md
Outdated
|
||
## Requirements | ||
The scanning code requires an `rpmdb` binary to be available in the executing systems `PATH`. | ||
Be warned that RPM installed via `brew` on OSX *will not work correctly*. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, now I am curious why this would not work :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added an explanation. I have not investigated why that is, but if you use rpmdb
installed via Brew to rebuild the RPM DB, it will result in an empty DB.
tools/local-nodescanner/README.md
Outdated
As of writing this readme, only RHCOS RPM components are supported by the Node Scan. | ||
Therefore, not a full filesystem is needed. The minimal folder/file structure needed for a scan to succeed is: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The sentences would say the same when we remove the first two:
As of writing this readme, only RHCOS RPM components are supported by the Node Scan. | |
Therefore, not a full filesystem is needed. The minimal folder/file structure needed for a scan to succeed is: | |
The minimal folder/file structure needed for a scan to succeed is: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
tools/local-nodescanner/README.md
Outdated
- `/etc/redhat-release` with contents denoting an RHCOS system (e.g. `Red Hat Enterprise Linux CoreOS release 4.12`) | ||
- `/usr/share/rpm` containing the RPM database |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We also need the content_sets json file or the scanner won't be able to find CPEs for scanning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the os-release
, I grabbed an RHCOS 4.9 version, which has hardcoded CPEs. Hence I didn't catch that. Thanks!
I have now corrected the os-release to 4.12 and added the content_sets.json to required files.
tools/local-nodescanner/main.go
Outdated
func main() { | ||
flag.CommandLine = flag.NewFlagSet(os.Args[0], flag.ExitOnError) | ||
fPath := flag.String("fspath", "/host", "Path to the root folder of a filesystem") | ||
fRHCOSrequired := flag.Bool("rhcosRequired", true, "Fails scan if filesystem is not RHCOS. Node Scanning only works on RHCOS.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
filesystem is not RHCOS
it is actually the OS, not the filesystem. Maybe this could be rephrased?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I rephrased it to make it more clear that the path needs to point to a filesystem resulting from running RHCOS
96889f1
to
0988915
Compare
After discussions in a Maple Demo Session, I have created a follow-up ticket with more feature ideas for this local node scanner: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Il looks good, but I found some minor issues. Giving it green, but please check them
tools/local-nodescanner/README.md
Outdated
|
||
|
||
|
||
## Requirements |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Markdown linter would scream here seeing so many empty lines ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch! Done
tools/local-nodescanner/README.md
Outdated
## Running the Docker image | ||
The Docker image only requires the path to a target filesystem to be scanned. | ||
As the default for `fspath` is set to `/host`, one can run the image without changes when mounting the target fs to the right path: | ||
`docker run -it -v /path/to/rhcos/fs:/host local-nodescanner:2.29.x-5-g7a3b50ef72-dirty` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would that work here?
`docker run -it -v /path/to/rhcos/fs:/host local-nodescanner:2.29.x-5-g7a3b50ef72-dirty` | |
`docker run -it -v /path/to/rhcos/fs:/host local-nodescanner:$(make tag)` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That works, great idea!
The only required flag is the path to a filesystem. | ||
This can be a RO-mount of a running system (e.g. `/host` in the Compliance or Node-Scanner images), | ||
or an unpacked filesystem, e.g. from a Docker image or ISO. | ||
Refer to `testdata/NodeScanning/rhcos4.12-minimal.tar.gz` for an archive containing a minimal example. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was hoping that we get a bit more instructions how to handle that 17MB file - could we maybe get a command where we extract it to some tmp location and then do docker run
with mounting it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have added a complete working example that should get anyone up and running. See L25-L31 in the README
tools/local-nodescanner/main.go
Outdated
if components.CertifiedRHELComponents.ContentSets != nil { | ||
log.Infof("Number of discovered ContentSets: %v", len(components.CertifiedRHELComponents.ContentSets)) | ||
for _, cs := range components.CertifiedRHELComponents.ContentSets { | ||
log.Debugf("CPE: %v", cs) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
log.Debugf("CPE: %v", cs) | |
log.Debugf("Content set: %v", cs) |
|
||
# Local Node Scanner | ||
.PHONY: local-nodescanner | ||
local-nodescanner: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is the idea that this should only be used inside a container? Otherwise, Mac users won't be able to use the binary directly :(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea is to have maximum flexibility. I have added a UBI 9 container target in this PR to make it runnable anywhere, but we could add more, e.g. UBI 8 or even Fedora latest for a bleeding edge RPM version.
The binary can either be used for tests and/or CI, or as a debug entry point for local debugging. That local debugging would not work on bare metal OSX w.r.t. RPM packages, but still might be useful, or could be done in the container.
tools/local-nodescanner/main.go
Outdated
flag.CommandLine = flag.NewFlagSet(os.Args[0], flag.ExitOnError) | ||
fPath := flag.String("fspath", "/host", "Path to the root folder of a filesystem") | ||
fRHCOSrequired := flag.Bool("rhcosRequired", true, "Fails scan if path does not contain a filesystem generated by RHCOS. Node Scanning only works on RHCOS.") | ||
fUncertifiedRHEL := flag.Bool("uncertifiedRhel", false, "Set true for CentOS and false for RHEL.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: uncertifiedRHEL
(not sure if that breaks flag name conventions)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would make it harder to use in the command line, assuming it's one of the intended use-cases of the tool? I would use rhcos-required
or rchosrequired
, honestly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have renamed both flags, see 07e3382
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
feeling a bit uneasy about pushing a 17MB file to the repo. How was this generated? Can we just recreate it on-demand? Maybe add some make targets to pull and save the image or something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most of the 17MB is actually the RPM package DB of an RHCOS 4.12 installation.
AFAIK there is no Docker image for RHCOS available, so I generated this by spinning a cluster and then manually pulling the RPM DB plus the additional text/json files that Node Scanning relies on.
I don't know whether we can automate that process or where to get a pre-populated RPM DB.
I remember that we found the download link of an RHCOS live image, though we would need to check whether that comes with a populated DB at rest or if it needs to be started.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@RTann I have checked and there is one way I can think of:
- Download the raw live rootfs from OpenShift (e.g. here)
- Unpack the img with
cpio
- Unpack the contained squashfs with
unsquashfs
- Navigate the resulting raw ostree to find the root volume
- Copy all required files into our
/testdata
folder
If I can figure out a reliable way of navigating the ostree layers (all hashes), I could build this as a makefile target and parametrize the script to download a specific RHCOS version.
I know that 17MB is quite a bit, but I don't know whether we can build automation robust enough to not break with the next RHCOS update.
What do you think?
tools/local-nodescanner/main.go
Outdated
log.Errorf("Encountered error while scanning: %v", err) | ||
} | ||
|
||
printResultsToTTY(components) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: You are simply writing to stdout, which might not be a TTY and can be some other file type. I would replace TTY
with Stdout
or just printResults()
.
tools/local-nodescanner/main.go
Outdated
flag.CommandLine = flag.NewFlagSet(os.Args[0], flag.ExitOnError) | ||
fPath := flag.String("fspath", "/host", "Path to the root folder of a filesystem") | ||
fRHCOSrequired := flag.Bool("rhcosRequired", true, "Fails scan if path does not contain a filesystem generated by RHCOS. Node Scanning only works on RHCOS.") | ||
fUncertifiedRHEL := flag.Bool("uncertifiedRhel", false, "Set true for CentOS and false for RHEL.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would make it harder to use in the command line, assuming it's one of the intended use-cases of the tool? I would use rhcos-required
or rchosrequired
, honestly.
Makefile
Outdated
.PHONY: local-nodescanner | ||
local-nodescanner: | ||
@echo "+ $@" | ||
GOOS=linux GOARCH=amd64 go build -trimpath -o ./tools/bin/local-nodescanner ./tools/local-nodescanner |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we build this inside our $(BUILD_IMAGE)
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to keep the tool rather isolated, but if you think we should use the build image, I'm happy to move that over into it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By isolation, do you mean minimizing dependencies? If yes, I think it's a very good goal.
If the primary goal of the tool is to aid development and local testing, I think it is OK not to use the build image to build it. Plan to have this evolve into something we can leverage in CI. Using the builder image might be necessary to ensure the built environment doesn't affect the final binary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the feedback! I've introduced a new dockerized build that is based on the builder image. Let me know what you think!
See 07e3382
- Update help string in main - Correct README info - Add minimal RHCOS 4.12 FS example
- Rename cmd flags - Introduce dockerized build based on builder
07e3382
to
2e4511d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious to know what will be the outcome of #1164 (comment), but otherwise, LGTM.
db691c6
to
1b12dd0
Compare
@jvdm / @RTann Regarding a makefile target: I have hit my timebox trying to make this work. It works on Linux, but fails on OSX when trying to use |
To make local experimentation and debugging with Node Scanning code easier, this PR introduces a CLI binary that calls said code.
For the scan to work, the binary requires the path to a folder containing a filesystem.
As the Node Scanning code requires the
rpmdb
binary to be present in the PATH, additionally to the CLI binary, also a self-contained Docker image is introduced to make running the binary possible on common dev platforms.After discussions in a Maple Demo Session, I have created a follow-up ticket with more feature ideas for this local node scanner:
ROX-16621.