Well, I may have my answer thanks to GitLab: https://gitlab.com/gitlab-org/gitlab-ce/issues/13784
Going to start experimenting and see how it goes. Will probably have to find some method to deadlock since I doubt Dev subscriptions allow dozens of subscriptions to fire off at once. On Tue, Aug 6, 2019 at 11:37 AM Sean <[email protected]> wrote: > To sort of backup Trevor, I wasn't aware of the download link that Shawn > had in his email. I work in the Govt/Mil space and we apply DISA STIG for > RHEL to CentOS and Scientific Linux. Doing so satisfies the ISSM's. My > govt. customer doesn't want to buy RHEL, he's not supporting a 24/7 > operation that has any real uptime demands, but he has govt customers who > run RHEL. That said, having access to a RHEL ISO image that I can install, > but then not update or add any packages to w/o a subscription is pretty > useless, even for testing purposes. We self-host Gitlab Enterprise and I > attempt (poorly) to provide reference artifacts of compliance reports that > are required for us produce in for operations out of my CI pipelines also. > The stuff I produce is used by other IT groups beyond my own, so having the > ability to provide these compliance reporting artifacts for RHEL would be > very useful. > > Further, since reading Shawn's email, I downloaded the RHEL 8 ISO, > installed in a VirtualBox VM to tinker with. I can't even easily install > vbox tools to keep the VM from trapping my mouse. I also can't easily add > packages or check for an update with out a subscription hassle. Sure, > maybe I can spend an a couple hours figuring out how to get the tools > installed with out a subscription...but again it's a hassle and why go > through that when CentOS is an easy button? Heck, with CentOS, its likely > that I don't even need to craft my own system, I can just go grab one > someone else built with Vagrant or Docker. > > I guess since I'm ranting a bit... Container testing provides limited use > with things like STIG compliance, since you need "real" systems with kernel > params, systemd, disk partitions, and such to get a full picture. There > are so many functional gaps between being STIG compliant and having a > system that actually works for whatever it's purpose might be. Having a > means to test things seems pretty important for all of us in this arena. > > Just two examples... > 1) RH Satellite / Foreman on a system with RHEL-07-021024 applied doesn't > work - https://access.redhat.com/solutions/3993801. It can be made to > work by adding "-Djava.io.tmpdir=/some/other/temporary/directory" to the > JAVA_ARGS variable in /etc/sysconfig/puppetserver. > 2) Having selinux contain users to staff_u (per RHEL-07-020020) and > attempting to burn a DVD from Gnome with Brasero fails miserably. In order > to even discover the whole reason why, you have unmask the selinux hidden > denials. Can I automate a test that validates this functionality?... > probably not, but why even bother trying on RHEL with the hassle with > subscriptions? > > --Sean > > > On Mon, Aug 5, 2019 at 6:29 PM Trevor Vaughan <[email protected]> > wrote: > >> Someone throw me an example of using it in Travis CI, under Docker, with >> access to repo updates and another example of using it via Vagrant in >> GitLab.com and I'm totally in. >> >> I gave up trying to figure out a way to do it without putting my >> developer key in places where it doesn't look like I can put my developer >> key. Now, If I'm allowed to put my developer key in a Git repo and let it >> fly to the four winds without getting in trouble, that's really easy! >> Otherwise, someone needs to hop on one of the 80 places that RedHat has >> technical blogs and clue me in. >> >> Alternatively, giving FOSS projects free runners in a Red Hat cloud that >> has access to repo updates would work. >> >> Heck, AppVeyor even lets me test on Windows easily (as does Vagrant in >> many cases) but trying to test on RHEL in a public CI system is more work >> than it's worth. >> >> In terms of the flow down, I'm not using this for validation on any sort >> of real system and am making no claims that it means anything. What I'm >> doing is using what the rest of the FOSS world uses to develop and doing >> something that lets me know if there are going to be absolutely >> catastrophic effects when I test on RHEL without needing to figure out how >> to get developer keys working in GitLab and/or Travis. >> >> Trevor >> >> On Mon, Aug 5, 2019 at 1:34 PM Shawn Wells <[email protected]> wrote: >> >>> >>> On 8/5/19 10:12 AM, Trevor Vaughan wrote: >>> > Personally, I would like it if I could just flip a switch and tell it >>> > to build *all* profiles for the 'RedHat family'. >>> > >>> > Primarily, I use this for testing and just kicking around new ideas >>> > via Vagrant since getting ahold of "real" RedHat is still not viable >>> > in public Travis CI via Vagrant. >>> >>> >>> With RHEL being free for development [0], the release of RHEL Universal >>> Base Image [1] how is that still the case? >>> >>> There's really zero excuse for continued use of CentOS, especially for >>> Government systems. >>> >>> >>> > I can do everything else, but not that. >>> >>> >>> >>> [0] >>> >>> https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-developer-subscription-now-available/ >>> >>> [1] >>> https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image >>> _______________________________________________ >>> scap-security-guide mailing list -- >>> [email protected] >>> To unsubscribe send an email to >>> [email protected] >>> Fedora Code of Conduct: >>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >>> List Archives: >>> https://lists.fedorahosted.org/archives/list/[email protected] >>> >> >> >> -- >> Trevor Vaughan >> Vice President, Onyx Point, Inc >> (410) 541-6699 x788 >> >> -- This account not approved for unencrypted proprietary information -- >> _______________________________________________ >> scap-security-guide mailing list -- >> [email protected] >> To unsubscribe send an email to >> [email protected] >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedorahosted.org/archives/list/[email protected] >> > _______________________________________________ > scap-security-guide mailing list -- > [email protected] > To unsubscribe send an email to > [email protected] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/[email protected] > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information --
_______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
