Support for atomic help feature

[matusmarhefka]

• Added container/help.sh to print basic info about openscap image
  including its version and info about bundled OpenSCAP packages.
• generate-dockerfile.py extended to support atomic help feature
• Example usage:
  sudo atomic help openscap
  or:
  sudo atomic help openscap | grep version

[pep8speaks]

Hello @matusmarhefka! Thanks for updating the PR.

• In the file generate-dockerfile.py, following are the PEP8 issues :

Line 10:80: E501 line too long (118 > 79 characters)
Line 11:80: E501 line too long (222 > 79 characters)
Line 13:80: E501 line too long (229 > 79 characters)
Line 15:80: E501 line too long (92 > 79 characters)
Line 17:80: E501 line too long (178 > 79 characters)
Line 39:13: E203 whitespace before ':'
Line 40:11: E203 whitespace before ':'
Line 48:80: E501 line too long (84 > 79 characters)
Line 76:80: E501 line too long (88 > 79 characters)
Line 81:13: E128 continuation line under-indented for visual indent
Line 83:9: E128 continuation line under-indented for visual indent
Line 85:9: E128 continuation line under-indented for visual indent
Line 87:9: E128 continuation line under-indented for visual indent
Line 87:80: E501 line too long (81 > 79 characters)
Line 88:80: E501 line too long (80 > 79 characters)
Line 89:9: E128 continuation line under-indented for visual indent
Line 90:80: E501 line too long (88 > 79 characters)
Line 91:9: E128 continuation line under-indented for visual indent
Line 93:9: E128 continuation line under-indented for visual indent
Line 95:61: E711 comparison to None should be 'if cond is not None:'
Line 96:9: E125 continuation line with same indent as next logical line
Line 96:9: E128 continuation line under-indented for visual indent
Line 105:80: E501 line too long (82 > 79 characters)
Line 106:80: E501 line too long (82 > 79 characters)
Line 131:34: E711 comparison to None should be 'if cond is not None:'
Line 135:80: E501 line too long (80 > 79 characters)
Line 136:80: E501 line too long (80 > 79 characters)
Line 137:80: E501 line too long (140 > 79 characters)
Line 149:29: E711 comparison to None should be 'if cond is not None:'
Line 154:80: E501 line too long (84 > 79 characters)
Line 165:26: E231 missing whitespace after ','
Line 166:32: E711 comparison to None should be 'if cond is not None:'
Line 187:80: E501 line too long (106 > 79 characters)
Line 190:80: E501 line too long (90 > 79 characters)
Line 194:80: E501 line too long (88 > 79 characters)
Line 212:80: E501 line too long (90 > 79 characters)
Line 218:1: E305 expected 2 blank lines after class or function definition, found 1

Comment last updated on November 07, 2017 at 16:35 Hours UTC

[jan-cerny]

I don't think this is the best description of OpenSCAP. Why it talks about XCCDF format only? Could it mention SCAP standard first? Do you think we could describe what OpenSCAP provides in terms of container scanning?

[matusmarhefka]

I just put the text from RH container registry there: https://access.redhat.com/containers/?tab=overview#/registry.access.redhat.com/rhel7/openscap

[matusmarhefka]

@jan-cerny What should we put there? Do you have some better short description which can be used?

[jan-cerny]

@matusmarhefka OK, then we might want to update the description in Red Hat Registry as well. I think the XCCDF support isn't the most exciting feature. It's not a big problem, I just think the description could be better.

Personally, I would mention there what is SCAP, what scan types the image provides maybe what are main use-cases.

[jan-cerny]

This will print pretty long output, especially on Fedora, where we ship CentOS and Ubuntu and Scientific and many other datastreams.

[jan-cerny]

818 lines on my laptop

[matusmarhefka]

Yes, but at least user has an easy way how to know what can be scanned. Before, you just had image with no information about datastreams or profiles and it was required to run docker image and know correct path to datastreams if you wanted to know what products and profiles can be used for scanning. So yes, it is long, but atomic help opens it for you in less and you can search for ds files/profiles easily which is much better and user friendly than running image with docker and searching for it manually.

[jan-cerny]

@matusmarhefka I understand your point but I don't think that anybody can read it.

[jan-cerny]

@matusmarhefka Please fix the conflicts.

[matusmarhefka]

Commit f392eb8 removes printing information about bundled datastreams and profiles. container/help.sh now only prints image version, description and versions of OpenSCAP RPM packages bundled inside the image. Version and description is taken from the image labels so the container/help.sh script itself does not introduce any help text about the image.

[matusmarhefka]

@jan-cerny I think this can be merged. I reported a new issue on how to provide a user with info about datastreams and profiles provided by openscap container image here (for the following discussion and tracking of other PRs related to that): #122

[jan-cerny]

@matusmarhefka Thank you very much! Great!.