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 <[email protected]> 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 <[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 -- > -- 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]
