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(a)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(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 --
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --