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
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 <tvaughan(a)onyxpoint.com>
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 <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
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-subs...
>>
>> [1]
>>
https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image
>> _______________________________________________
>> scap-security-guide mailing list --
>> scap-security-guide(a)lists.fedorahosted.org
>> To unsubscribe send an email to
>> scap-security-guide-leave(a)lists.fedorahosted.org
>> 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/scap-security-guide@lists.fe...
>>
>
>
> --
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> (410) 541-6699 x788
>
> -- This account not approved for unencrypted proprietary information --
> _______________________________________________
> scap-security-guide mailing list --
> scap-security-guide(a)lists.fedorahosted.org
> To unsubscribe send an email to
> scap-security-guide-leave(a)lists.fedorahosted.org
> 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/scap-security-guide@lists.fe...
>
_______________________________________________
scap-security-guide mailing list --
scap-security-guide(a)lists.fedorahosted.org
To unsubscribe send an email to
scap-security-guide-leave(a)lists.fedorahosted.org
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/scap-security-guide@lists.fe...
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --