My mind does still boggle a bit that you have to pass the username and password at the command line to subscription-manager.

On Wed, Aug 7, 2019 at 2:39 PM Trevor Vaughan <tvaughan@onyxpoint.com> wrote:
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 <smalder73@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@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@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-subscription-now-available/

[1] https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image
_______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@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.fedorahosted.org


--
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@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@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.fedorahosted.org
_______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@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.fedorahosted.org


--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --


--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --