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 <smalder73(a)gmail.com> wrote:
To sort of backup Trevor, I wasn't aware of the download link
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
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
On Mon, Aug 5, 2019 at 6:29 PM Trevor Vaughan <tvaughan(a)onyxpoint.com>
> 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
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.
> On Mon, Aug 5, 2019 at 1:34 PM Shawn Wells <shawn(a)redhat.com> 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
>> > in public Travis CI via Vagrant.
>> With RHEL being free for development , the release of RHEL Universal
>> Base Image  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.
>> scap-security-guide mailing list --
>> To unsubscribe send an email to
>> Fedora Code of Conduct:
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> (410) 541-6699 x788
> -- This account not approved for unencrypted proprietary information --
> scap-security-guide mailing list --
> To unsubscribe send an email to
> Fedora Code of Conduct:
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
scap-security-guide mailing list --
To unsubscribe send an email to
Fedora Code of Conduct:
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --