From jan.kratochvil at redhat.com Mon Sep 5 20:19:42 2016 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Mon, 5 Sep 2016 22:19:42 +0200 Subject: [scl.org] Missing DTS 4 - Developer Toolset 4 Message-ID: <20160905201942.GA27135@host1.jankratochvil.net> Hi, there is only HTML page for DTS (Developer Toolset) version 3: https://www.softwarecollections.org/en/scls/rhscl/devtoolset-3/ with files at: http://mirror.centos.org/centos/7/sclo/x86_64/rh/devtoolset-3/ But Red Hat also released DTS-4.0 which has no HTML page but files are at: http://mirror.centos.org/centos/7/sclo/x86_64/rh/devtoolset-4/ Red Hat also released DTS-4.1 but I see neither HTML nor files there. Should be DTS-4.1 uploaded there at all? Who could do that? Thanks, Jan From contact at dipohl.de Fri Sep 9 17:21:59 2016 From: contact at dipohl.de (Gabriele Pohl) Date: Fri, 9 Sep 2016 19:21:59 +0200 Subject: [scl.org] Enabe Ruby193 in postfix context Message-ID: <20160909192159.72862f0c@niva.dipohl.de> Hi, I hope you can give advice for the following use case. I want to setup encrypted mailing list with Schleuder2 [1] on my CentOS 6 server. Although the installation guide [2] states that ruby >=1.8.6. will be sufficient I run into errors during installation concerning one gem that wants ruby >=1.9.3 Therefore I made my next try to install Schleuder2 with your software collection Ruby193. The installation was successful then. But I don't know how to solve the following issue to get it up running and ready to be used. Incoming mail for the mailing list will be forwarded to the Listserver Schleuder configured by entries in /etc/aliases listname: "|/path/to/schleuderdir/bin/schleuder listname at hostname" listname-request: "|/path/to/schleuderdir/bin/schleuder listname at hostname" listname-bounce: "|/path/to/schleuderdir/bin/schleuder listname at hostname" listname-sendkey: "|/path/to/schleuderdir/bin/schleuder listname at hostname" listname-owner: "|/path/to/schleuderdir/bin/schleuder listname at hostname" and until now postfix throws exception in maillog: Command died with status 127: "/opt/rh/ruby193/root/usr/local/bin/schleuder listname at hostname". Command output: /opt/rh/ruby193/root/usr/bin/ruby: error while loading shared libraries: libruby.so.1.9: cannot open shared object file: No such file or directory" I tried to apply a recipe, that I found in your mailing list archive https://www.redhat.com/archives/sclorg/2016-June/msg00008.html test -f /opt/rh/ruby193/enable && source /opt/rh/ruby193/enable I stored this command to /etc/profile.d/ruby.sh It resulted in having ruby193 enabled in all user shells. But the error in postfix aliases context was not solved by it. I restarted the postfix MTA and also rebooted the whole machine with no success in this issue. I will be happy about a helping hand. With kind regards, Gabriele [1] http://schleuder2.nadir.org/ [2] http://schleuder2.nadir.org/documentation/v2.2/installation.html From ppisar at redhat.com Mon Sep 12 08:19:21 2016 From: ppisar at redhat.com (Petr Pisar) Date: Mon, 12 Sep 2016 10:19:21 +0200 Subject: [scl.org] Enabe Ruby193 in postfix context In-Reply-To: <20160909192159.72862f0c@niva.dipohl.de> References: <20160909192159.72862f0c@niva.dipohl.de> Message-ID: <20160912081921.GB2349@dhcp-0-146.brq.redhat.com> On Fri, Sep 09, 2016 at 07:21:59PM +0200, Gabriele Pohl wrote: > I tried to apply a recipe, that I found in your mailing list archive > https://www.redhat.com/archives/sclorg/2016-June/msg00008.html > > test -f /opt/rh/ruby193/enable && source /opt/rh/ruby193/enable > > I stored this command to /etc/profile.d/ruby.sh > > It resulted in having ruby193 enabled in all user shells. > > But the error in postfix aliases context was > not solved by it. Because profile scripts are executed only for login and interactive shells. The scripts run by postfix are neither of them. Either you can play with BASH_ENV environment variable (read bash(1) manual) or, I recommend, create a simple wrapper around your ruby script that will siply execute the real script in the enabled enviroment, like: #!/bin/sh scl enable ruby193 /the/real/script -- Petr -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: not available URL: From contact at dipohl.de Tue Sep 13 15:35:31 2016 From: contact at dipohl.de (Gabriele Pohl) Date: Tue, 13 Sep 2016 17:35:31 +0200 Subject: [scl.org] Enabe Ruby193 in postfix context In-Reply-To: <20160912081921.GB2349@dhcp-0-146.brq.redhat.com> References: <20160909192159.72862f0c@niva.dipohl.de> <20160912081921.GB2349@dhcp-0-146.brq.redhat.com> Message-ID: <20160913173531.4449c0ac@niva.dipohl.de> Hi Petr, On Mon, 12 Sep 2016 10:19:21 +0200 Petr Pisar wrote: > On Fri, Sep 09, 2016 at 07:21:59PM +0200, Gabriele Pohl wrote: > > test -f /opt/rh/ruby193/enable && source /opt/rh/ruby193/enable > > > > I stored this command to /etc/profile.d/ruby.sh > > > > It resulted in having ruby193 enabled in all user shells. > > > > But the error in postfix aliases context was > > not solved by it. > > Because profile scripts are executed only for login and interactive shells. > The scripts run by postfix are neither of them. > > I recommend, create a simple wrapper around your ruby script that will > siply execute the real script in the enabled enviroment, like: > > #!/bin/sh > scl enable ruby193 /the/real/script I tried this, but it doesn't work either: Created a wrapper script "schleuder-wrapper.sh" with following content: #!/bin/sh scl enable ruby193 /opt/rh/ruby193/root/usr/local/bin/schleuder listname at hostname Then I changed the entry in /etc/aliases to this: name: "|/schleuder-wrapper.sh" This is the error message in postfix log, when sending mail to the alias name: Command died with status 1: "/schleuder-wrapper.sh". Command output: Unable to open /etc/scl/prefixes//opt/rh/ruby193/root/usr/local/bin/schleuder! Can you explain what happened here? fyi and thanks for your support! Gabriele From dominic at cleal.org Wed Sep 14 07:07:12 2016 From: dominic at cleal.org (Dominic Cleal) Date: Wed, 14 Sep 2016 08:07:12 +0100 Subject: [scl.org] Enabe Ruby193 in postfix context In-Reply-To: <20160913173531.4449c0ac@niva.dipohl.de> References: <20160909192159.72862f0c@niva.dipohl.de> <20160912081921.GB2349@dhcp-0-146.brq.redhat.com> <20160913173531.4449c0ac@niva.dipohl.de> Message-ID: <6a9b889c-1db6-9e82-f259-f09ed7a06d62@cleal.org> On 13/09/16 16:35, Gabriele Pohl wrote: > Hi Petr, > > On Mon, 12 Sep 2016 10:19:21 +0200 > Petr Pisar wrote: > >> > On Fri, Sep 09, 2016 at 07:21:59PM +0200, Gabriele Pohl wrote: >>> > > test -f /opt/rh/ruby193/enable && source /opt/rh/ruby193/enable >>> > > >>> > > I stored this command to /etc/profile.d/ruby.sh >>> > > >>> > > It resulted in having ruby193 enabled in all user shells. >>> > > >>> > > But the error in postfix aliases context was >>> > > not solved by it. >> > >> > Because profile scripts are executed only for login and interactive shells. >> > The scripts run by postfix are neither of them. >> > >> > I recommend, create a simple wrapper around your ruby script that will >> > siply execute the real script in the enabled enviroment, like: >> > >> > #!/bin/sh >> > scl enable ruby193 /the/real/script > I tried this, but it doesn't work either: > > Created a wrapper script "schleuder-wrapper.sh" with following content: > > #!/bin/sh > scl enable ruby193 /opt/rh/ruby193/root/usr/local/bin/schleuder listname at hostname The command must be quoted: scl enable ruby193 "/opt/rh/ruby193/root/usr/local/bin/schleuder listname at hostname" or use "--": scl enable ruby193 -- /opt/rh/ruby193/root/usr/local/bin/schleuder listname at hostname -- Dominic Cleal dominic at cleal.org From noah at coderanger.net Fri Sep 16 02:11:04 2016 From: noah at coderanger.net (Noah Kantrowitz) Date: Thu, 15 Sep 2016 19:11:04 -0700 Subject: [scl.org] Installing SCL packages on RHEL Message-ID: <9B295320-679B-40C1-A2E6-FBFDE0A8FC41@coderanger.net> Okay, to get the disclaimer out of the way, I understand that SCLo/CentOS packages are not supported by RedHat. I'm trying to get my Chef SCL code to work on RHEL again (CentOS works great via centos-release-scl). The official (from what I can tell) solution is `subscription-manager repos --enable rhel-server-rhscl-{6,7}-rpms`. The problem is this fails on most cloud-y RHEL installs as the EC2/Rackspace/whatever images don't come with a subscription setup and thus even though they (I think, the cloud licenses are weird and bespoke) could use the SCL subscription, the system won't allow it. EC2 has a (custom?) solution for this with a local RHUI server in each region that can be used to set up the SCL repository. This server is not reachable from outside EC2 though, so doesn't help on other cloud platforms. The next thing I thought to try is to use the SCLo/CentOS repositories directly for cloud users as they probably don't care too much about support or they would have set up a subscription. I can't figure out a stable way to do that though. From https://github.com/sclorg/centos-release-scl, I can do `yum-config-manager --add-repo=https://copr.fedoraproject.org/coprs/rhscl/centos-release-scl/repo/epel-7/rhscl-centos-release-scl-epel-7.repo` but this only activates the sclo/ repo, not rh/ so I can't install the recompiles of the RHSCL packages (i.e. most of them). I could set the http://mirror.centos.org/centos/6/sclo/x86_64/rh/ repository manually, but I would need a copy of the GPG to import. I've filed https://bugs.centos.org/view.php?id=11468 to request the GPG key be made available via centos.org but I would imagine any changes there will take some time. So with that wall of text, what's the best way to get SCL packages on RedHat for _all_ RHEL users? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From hhorak at redhat.com Fri Sep 16 12:07:49 2016 From: hhorak at redhat.com (Honza Horak) Date: Fri, 16 Sep 2016 14:07:49 +0200 Subject: [scl.org] Missing DTS 4 - Developer Toolset 4 In-Reply-To: <20160905201942.GA27135@host1.jankratochvil.net> References: <20160905201942.GA27135@host1.jankratochvil.net> Message-ID: On 09/05/2016 10:19 PM, Jan Kratochvil wrote: > Hi, > > there is only HTML page for DTS (Developer Toolset) version 3: > https://www.softwarecollections.org/en/scls/rhscl/devtoolset-3/ > with files at: > http://mirror.centos.org/centos/7/sclo/x86_64/rh/devtoolset-3/ > > But Red Hat also released DTS-4.0 which has no HTML page but files are at: > http://mirror.centos.org/centos/7/sclo/x86_64/rh/devtoolset-4/ > > Red Hat also released DTS-4.1 but I see neither HTML nor files there. > > Should be DTS-4.1 uploaded there at all? Who could do that? Files are here: http://mirror.centos.org/centos/7/sclo/x86_64/rh/devtoolset-4/ and HTML here: https://www.softwarecollections.org/en/scls/rhscl/devtoolset-4/ It all looks correct to me, but maybe it was fixed meantime. Let me know if you still see something missing. Thanks, Honza > Thanks, > Jan > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > From hhorak at redhat.com Fri Sep 16 14:26:40 2016 From: hhorak at redhat.com (Honza Horak) Date: Fri, 16 Sep 2016 16:26:40 +0200 Subject: [scl.org] Installing SCL packages on RHEL In-Reply-To: <9B295320-679B-40C1-A2E6-FBFDE0A8FC41@coderanger.net> References: <9B295320-679B-40C1-A2E6-FBFDE0A8FC41@coderanger.net> Message-ID: I'm afraid I won't have a clear answer right now, but will try to help at least where I can. On 09/16/2016 04:11 AM, Noah Kantrowitz wrote: > Okay, to get the disclaimer out of the way, I understand that SCLo/CentOS packages are not supported by RedHat. I'm trying to get my Chef SCL code to work on RHEL again (CentOS works great via centos-release-scl). The official (from what I can tell) solution is `subscription-manager repos --enable rhel-server-rhscl-{6,7}-rpms`. The problem is this fails on most cloud-y RHEL installs as the EC2/Rackspace/whatever images don't come with a subscription setup and thus even though they (I think, the cloud licenses are weird and bespoke) could use the SCL subscription, the system won't allow it. So, are you're hitting the issue described in https://access.redhat.com/solutions/1120983? > EC2 has a (custom?) solution for this with a local RHUI server in each region that can be used to set up the SCL repository. This server is not reachable from outside EC2 though, so doesn't help on other cloud platforms. It seems like the solution above does work for EC2 but not for other providers, right? In any case, I'd recommend to contact RH support, they already might have seen issues like this and might have a solution. > The next thing I thought to try is to use the SCLo/CentOS repositories directly for cloud users as they probably don't care too much about support or they would have set up a subscription. I can't figure out a stable way to do that though. From https://github.com/sclorg/centos-release-scl, I can do `yum-config-manager --add-repo=https://copr.fedoraproject.org/coprs/rhscl/centos-release-scl/repo/epel-7/rhscl-centos-release-scl-epel-7.repo` but this only activates the sclo/ repo, not rh/ so I can't install the recompiles of the RHSCL packages (i.e. most of them). The problem I have with this particular solution is that SCLo packages from CentOS were never meant to be run on RHEL, nobody tests them on RHEL and simply said for RHEL the solution is RHSCL channel. Although I understand you might be frustrated by not being able to do it simply the correct way.. > I could set the http://mirror.centos.org/centos/6/sclo/x86_64/rh/ repository manually, but I would need a copy of the GPG to import. I've filed https://bugs.centos.org/view.php?id=11468 to request the GPG key be made available via centos.org but I would imagine any changes there will take some time. > > So with that wall of text, what's the best way to get SCL packages on RedHat for _all_ RHEL users? That's exactly which way we should focus on, but I'm not able to help right now, since I don't have enough information about it. I'll try to fill gaps in my knowledge, but as mentioned above, I'd recommend to contact the RH support with this problem. Honza > > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > From jan.kratochvil at redhat.com Fri Sep 16 17:20:42 2016 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Fri, 16 Sep 2016 19:20:42 +0200 Subject: [scl.org] Missing DTS 4 - Developer Toolset 4 In-Reply-To: References: <20160905201942.GA27135@host1.jankratochvil.net> Message-ID: <20160916172042.GA11361@host1.jankratochvil.net> On Fri, 16 Sep 2016 14:07:49 +0200, Honza Horak wrote: > On 09/05/2016 10:19 PM, Jan Kratochvil wrote: > > But Red Hat also released DTS-4.0 which has no HTML page but files are at: > > http://mirror.centos.org/centos/7/sclo/x86_64/rh/devtoolset-4/ > > > > Red Hat also released DTS-4.1 but I see neither HTML nor files there. > > Files are here: > http://mirror.centos.org/centos/7/sclo/x86_64/rh/devtoolset-4/ These files are for DTS-4.0. Not for DTS-4.1. softwarecollections.org link: http://mirror.centos.org/centos/7/sclo/x86_64/rh/devtoolset-4/devtoolset-4-gdb-7.10-20.el7.x86_64.rpm Internal Red Hat link for SCL-2.1 == DTS-4.0: http://download.devel.redhat.com/released/RHSCL/2.1/RHEL-7/Workstation/source/tree/Packages/devtoolset-4-gdb-7.10-20.el7.src.rpm Internal Red Hat link for SCL-2.2 == DTS-4.1: http://download.devel.redhat.com/released/RHSCL/2.2/RHEL-7/Workstation/source/tree/Packages/devtoolset-4-gdb-7.11-67.el7.src.rpm > and HTML here: > https://www.softwarecollections.org/en/scls/rhscl/devtoolset-4/ The HTML page is there, sorry, I have made some mistake while searching for it. Thanks, Jan From noah at coderanger.net Fri Sep 16 18:27:35 2016 From: noah at coderanger.net (Noah Kantrowitz) Date: Fri, 16 Sep 2016 11:27:35 -0700 Subject: [scl.org] Installing SCL packages on RHEL In-Reply-To: References: <9B295320-679B-40C1-A2E6-FBFDE0A8FC41@coderanger.net> Message-ID: <6182FB0C-2D21-4723-ABB5-9F9BF40AACC9@coderanger.net> > On Sep 16, 2016, at 7:26 AM, Honza Horak wrote: > > I'm afraid I won't have a clear answer right now, but will try to help at least where I can. > > On 09/16/2016 04:11 AM, Noah Kantrowitz wrote: >> Okay, to get the disclaimer out of the way, I understand that SCLo/CentOS packages are not supported by RedHat. I'm trying to get my Chef SCL code to work on RHEL again (CentOS works great via centos-release-scl). The official (from what I can tell) solution is `subscription-manager repos --enable rhel-server-rhscl-{6,7}-rpms`. The problem is this fails on most cloud-y RHEL installs as the EC2/Rackspace/whatever images don't come with a subscription setup and thus even though they (I think, the cloud licenses are weird and bespoke) could use the SCL subscription, the system won't allow it. > > So, are you're hitting the issue described in https://access.redhat.com/solutions/1120983? Except replace "EC2" with any other provider (Rackspace, Google Cloud, Azure, etc). > >> EC2 has a (custom?) solution for this with a local RHUI server in each region that can be used to set up the SCL repository. This server is not reachable from outside EC2 though, so doesn't help on other cloud platforms. > > It seems like the solution above does work for EC2 but not for other providers, right? In any case, I'd recommend to contact RH support, they already might have seen issues like this and might have a solution. Yes, but solving it for EC2 required Amazon to deploy quite a bit of infrastructure and modify their base images so I don't think this is likely to be a short-term help unless every cloud vendor does the same. > >> The next thing I thought to try is to use the SCLo/CentOS repositories directly for cloud users as they probably don't care too much about support or they would have set up a subscription. I can't figure out a stable way to do that though. From https://github.com/sclorg/centos-release-scl, I can do `yum-config-manager --add-repo=https://copr.fedoraproject.org/coprs/rhscl/centos-release-scl/repo/epel-7/rhscl-centos-release-scl-epel-7.repo` but this only activates the sclo/ repo, not rh/ so I can't install the recompiles of the RHSCL packages (i.e. most of them). > > The problem I have with this particular solution is that SCLo packages from CentOS were never meant to be run on RHEL, nobody tests them on RHEL and simply said for RHEL the solution is RHSCL channel. Although I understand you might be frustrated by not being able to do it simply the correct way.. This is no longer about correct or incorrect, I just want anything that works. > >> I could set the http://mirror.centos.org/centos/6/sclo/x86_64/rh/ repository manually, but I would need a copy of the GPG to import. I've filed https://bugs.centos.org/view.php?id=11468 to request the GPG key be made available via centos.org but I would imagine any changes there will take some time. >> >> So with that wall of text, what's the best way to get SCL packages on RedHat for _all_ RHEL users? > > That's exactly which way we should focus on, but I'm not able to help right now, since I don't have enough information about it. I'll try to fill gaps in my knowledge, but as mentioned above, I'd recommend to contact the RH support with this problem. How do I contact RH support for something like this? --Noah -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From contact at dipohl.de Sun Sep 18 11:31:59 2016 From: contact at dipohl.de (Gabriele Pohl) Date: Sun, 18 Sep 2016 13:31:59 +0200 Subject: [scl.org] Enabe Ruby193 in postfix context In-Reply-To: <6a9b889c-1db6-9e82-f259-f09ed7a06d62@cleal.org> References: <20160909192159.72862f0c@niva.dipohl.de> <20160912081921.GB2349@dhcp-0-146.brq.redhat.com> <20160913173531.4449c0ac@niva.dipohl.de> <6a9b889c-1db6-9e82-f259-f09ed7a06d62@cleal.org> Message-ID: <20160918133159.6b17aeba@niva.dipohl.de> On Wed, 14 Sep 2016 08:07:12 +0100 Dominic Cleal wrote: > On 13/09/16 16:35, Gabriele Pohl wrote: > > > > On Mon, 12 Sep 2016 10:19:21 +0200 > > Petr Pisar wrote: > > > >> > I recommend, create a simple wrapper around your ruby script that will > >> > siply execute the real script in the enabled enviroment, like: > >> > > >> > #!/bin/sh > >> > scl enable ruby193 /the/real/script > > I tried this, but it doesn't work either: > > > > Created a wrapper script "schleuder-wrapper.sh" with following content: > > > > #!/bin/sh > > scl enable ruby193 /opt/rh/ruby193/root/usr/local/bin/schleuder listname at hostname > > The command must be quoted: > > scl enable ruby193 "/opt/rh/ruby193/root/usr/local/bin/schleuder > listname at hostname" That works as it seems, although I get another error now, but that is likely a problem in my current setup of Schleuder: Command died with status 1: "/usr/local/sbin/schleuder-wrapper.sh". Command output: A serious error occurred, please notify the administrators of this list or server! First I thought, that piping of the mail hadn't worked, but I tested with a cat command to file in the script, saw that it works in general. fyi & thanks for the hint! Gabriele From ncoghlan at redhat.com Mon Sep 19 06:57:17 2016 From: ncoghlan at redhat.com (Nick Coghlan) Date: Mon, 19 Sep 2016 16:57:17 +1000 Subject: [scl.org] Installing SCL packages on RHEL In-Reply-To: References: <9B295320-679B-40C1-A2E6-FBFDE0A8FC41@coderanger.net> Message-ID: On Sat, Sep 17, 2016 at 12:26 AM, Honza Horak wrote: > On 09/16/2016 04:11 AM, Noah Kantrowitz wrote: >> The next thing I thought to try is to use the SCLo/CentOS repositories >> directly for cloud users as they probably don't care too much about support >> or they would have set up a subscription. I can't figure out a stable way to >> do that though. From https://github.com/sclorg/centos-release-scl, I can do >> `yum-config-manager >> --add-repo=https://copr.fedoraproject.org/coprs/rhscl/centos-release-scl/repo/epel-7/rhscl-centos-release-scl-epel-7.repo` >> but this only activates the sclo/ repo, not rh/ so I can't install the >> recompiles of the RHSCL packages (i.e. most of them). > > The problem I have with this particular solution is that SCLo packages from > CentOS were never meant to be run on RHEL, nobody tests them on RHEL and > simply said for RHEL the solution is RHSCL channel. Although I understand > you might be frustrated by not being able to do it simply the correct way.. That's the case for all the "RHEL++" solutions like Fedora's EPEL, Rackspace's IUS, and SCLo itself though - while the main nominal user base for those services is folks running entirely self-supported environments on a community Linux distro, there are also lots of times where they're used as workarounds for challenges that people run into with the recommended approaches (whether that's the officially supported channels missing a specific component that someone wants, a user wanting a newer version of a component for a particular proof of concept, or, as is the case here, the officially recommended approach not yet being universally supported by all of Red Hat's redistribution partners). Consider the case of Red Hat's own sponsored upstream projects, for example - we want to make it as easy as possible for them to switch to SCLs as their recommended deployment environment, and by the very fact that someone is experimenting with the upstream version rather than the post-QA commercial Red Hat product, they're already saying they don't want or need official support for that particular activity. Do we really want to put those upstream projects in a position where they *need* to recommend CentOS over RHEL because there aren't any community-centric SCL enablement instructions that work reliably across all cloud providers that offer RHEL images? As long as folks that adopt workarounds are fully aware of the fact that they *are* temporary workarounds rather than long term substitutes for properly supported solutions, that's a better situation than leaving them completely stuck with no guidance that actually works universally *today*. For example, we could offer SCL consumption guidance on softwarecollections.org like the following: - For CentOS, use to set up the softwarecollections.org repositories - For RHEL, use to set up the Red Hat supported RHSCL repositories - If setting up the RHSCL repositories fails, and your organisation runs Red Hat Satellite, ensure your systems are correctly registered with Satellite first - if your system isn't able to subscribe directly to the Red Hat provided repositories, and you don't (as far as you are aware) have a Satellite instance available: - report the RHSCL enablement problem to your RHEL provider (whether that's a public cloud service or your internal IT organisation) - while waiting for them to fix the issue, use to set up the softwarecollections.org repositories - note explicitly that after the RHSCL channels are enabled, a RHEL system is also correctly configured to work as a container host for RHEL based, RHSCL enabled, containers We could also explicitly note that for Fedora, the typically recommended approach is to use the CentOS+SCLo approach inside a container, rather than rebuilding the SCLs themselves specifically for any given Fedora release. At the moment, SCLo doesn't offer any central guidance on how to *use* Software Collections, which makes it a bit of a choose-your-own-adventure exercise for potential adopters, and means you end up with a lot of *publisher* centric results (including softwarecollections.org itself) if you type "using software collections" into Google. Explicitly adopting an approach like the one I suggest above would: 1. Make softwarecollections.org a better resource for folks looking to consume *existing* Software Collections (whether Red Hat supported or community supported), rather than publish their own; 2. Let people know that we're aware of the current RHEL-specific cross-provider usability problem Noah pointed out and are working to fix it properly; 3. Help ensure that folks that encounter RHSCL channel registration problems are aware of how to troubleshoot and resolve them, rather than giving up on SCLs in general; and 4. Remove a barrier to wider adoption of SCLs as a deployment strategy, increasing the utility of softwarecollections.org as a place to publish community maintained collections for development stacks that Red Hat doesn't support commercially at all (akin to the community quickstarts for OpenShift v2, and the "bring your own container" feature in OpenShift v3) Cheers, Nick. -- Nick Coghlan Red Hat Platform Engineering, Brisbane From hhorak at redhat.com Mon Sep 19 07:32:29 2016 From: hhorak at redhat.com (Honza Horak) Date: Mon, 19 Sep 2016 09:32:29 +0200 Subject: [scl.org] Installing SCL packages on RHEL In-Reply-To: <6182FB0C-2D21-4723-ABB5-9F9BF40AACC9@coderanger.net> References: <9B295320-679B-40C1-A2E6-FBFDE0A8FC41@coderanger.net> <6182FB0C-2D21-4723-ABB5-9F9BF40AACC9@coderanger.net> Message-ID: <39c061ec-dd2d-a0bc-de88-76ad747cea4f@redhat.com> On 09/16/2016 08:27 PM, Noah Kantrowitz wrote: > >> On Sep 16, 2016, at 7:26 AM, Honza Horak wrote: >> >> I'm afraid I won't have a clear answer right now, but will try to help at least where I can. >> >> On 09/16/2016 04:11 AM, Noah Kantrowitz wrote: >>> Okay, to get the disclaimer out of the way, I understand that SCLo/CentOS packages are not supported by RedHat. I'm trying to get my Chef SCL code to work on RHEL again (CentOS works great via centos-release-scl). The official (from what I can tell) solution is `subscription-manager repos --enable rhel-server-rhscl-{6,7}-rpms`. The problem is this fails on most cloud-y RHEL installs as the EC2/Rackspace/whatever images don't come with a subscription setup and thus even though they (I think, the cloud licenses are weird and bespoke) could use the SCL subscription, the system won't allow it. >> >> So, are you're hitting the issue described in https://access.redhat.com/solutions/1120983? > > Except replace "EC2" with any other provider (Rackspace, Google Cloud, Azure, etc). > >> >>> EC2 has a (custom?) solution for this with a local RHUI server in each region that can be used to set up the SCL repository. This server is not reachable from outside EC2 though, so doesn't help on other cloud platforms. >> >> It seems like the solution above does work for EC2 but not for other providers, right? In any case, I'd recommend to contact RH support, they already might have seen issues like this and might have a solution. > > Yes, but solving it for EC2 required Amazon to deploy quite a bit of infrastructure and modify their base images so I don't think this is likely to be a short-term help unless every cloud vendor does the same. I see. But I don't understand why RHSCL is the problem and RHEL packages are not (or are they?). If the subscription does not work at all, then users are not able to install any packages, not only RHSCL, right? Since RHSCL packages often need something from the base RHEL, would it help at all to install SCL packages "the temporary way"? Or is it just problem of RHSCL channel that is problematic? >> >>> The next thing I thought to try is to use the SCLo/CentOS repositories directly for cloud users as they probably don't care too much about support or they would have set up a subscription. I can't figure out a stable way to do that though. From https://github.com/sclorg/centos-release-scl, I can do `yum-config-manager --add-repo=https://copr.fedoraproject.org/coprs/rhscl/centos-release-scl/repo/epel-7/rhscl-centos-release-scl-epel-7.repo` but this only activates the sclo/ repo, not rh/ so I can't install the recompiles of the RHSCL packages (i.e. most of them). >> >> The problem I have with this particular solution is that SCLo packages from CentOS were never meant to be run on RHEL, nobody tests them on RHEL and simply said for RHEL the solution is RHSCL channel. Although I understand you might be frustrated by not being able to do it simply the correct way.. > > This is no longer about correct or incorrect, I just want anything that works. > >> >>> I could set the http://mirror.centos.org/centos/6/sclo/x86_64/rh/ repository manually, but I would need a copy of the GPG to import. I've filed https://bugs.centos.org/view.php?id=11468 to request the GPG key be made available via centos.org but I would imagine any changes there will take some time. Well, the keys are the same for all SCLo packages on CentOS, so installing centos-release-scl package brings the missing key to the machine. >>> So with that wall of text, what's the best way to get SCL packages on RedHat for _all_ RHEL users? >> >> That's exactly which way we should focus on, but I'm not able to help right now, since I don't have enough information about it. I'll try to fill gaps in my knowledge, but as mentioned above, I'd recommend to contact the RH support with this problem. > > How do I contact RH support for something like this? Creating a support case is generally the first step I guess: https://access.redhat.com/support/cases/#/case/new Honza From noah at coderanger.net Mon Sep 19 20:51:19 2016 From: noah at coderanger.net (Noah Kantrowitz) Date: Mon, 19 Sep 2016 13:51:19 -0700 Subject: [scl.org] Installing SCL packages on RHEL In-Reply-To: <39c061ec-dd2d-a0bc-de88-76ad747cea4f@redhat.com> References: <9B295320-679B-40C1-A2E6-FBFDE0A8FC41@coderanger.net> <6182FB0C-2D21-4723-ABB5-9F9BF40AACC9@coderanger.net> <39c061ec-dd2d-a0bc-de88-76ad747cea4f@redhat.com> Message-ID: <0E4F17E9-614F-4976-B38B-6FB9E8739C01@coderanger.net> > On Sep 19, 2016, at 12:32 AM, Honza Horak wrote: > > On 09/16/2016 08:27 PM, Noah Kantrowitz wrote: >> >>> On Sep 16, 2016, at 7:26 AM, Honza Horak wrote: >>> >>> I'm afraid I won't have a clear answer right now, but will try to help at least where I can. >>> >>> On 09/16/2016 04:11 AM, Noah Kantrowitz wrote: >>>> Okay, to get the disclaimer out of the way, I understand that SCLo/CentOS packages are not supported by RedHat. I'm trying to get my Chef SCL code to work on RHEL again (CentOS works great via centos-release-scl). The official (from what I can tell) solution is `subscription-manager repos --enable rhel-server-rhscl-{6,7}-rpms`. The problem is this fails on most cloud-y RHEL installs as the EC2/Rackspace/whatever images don't come with a subscription setup and thus even though they (I think, the cloud licenses are weird and bespoke) could use the SCL subscription, the system won't allow it. >>> >>> So, are you're hitting the issue described in https://access.redhat.com/solutions/1120983? >> >> Except replace "EC2" with any other provider (Rackspace, Google Cloud, Azure, etc). >> >>> >>>> EC2 has a (custom?) solution for this with a local RHUI server in each region that can be used to set up the SCL repository. This server is not reachable from outside EC2 though, so doesn't help on other cloud platforms. >>> >>> It seems like the solution above does work for EC2 but not for other providers, right? In any case, I'd recommend to contact RH support, they already might have seen issues like this and might have a solution. >> >> Yes, but solving it for EC2 required Amazon to deploy quite a bit of infrastructure and modify their base images so I don't think this is likely to be a short-term help unless every cloud vendor does the same. > > I see. But I don't understand why RHSCL is the problem and RHEL packages are not (or are they?). If the subscription does not work at all, then users are not able to install any packages, not only RHSCL, right? Since RHSCL packages often need something from the base RHEL, would it help at all to install SCL packages "the temporary way"? Or is it just problem of RHSCL channel that is problematic? When RedHat partners with a cloud provider to offer RHEL, they work out something for package installs where no subscription is set up but you can still install things. It just seems like only Amazon has also worked out something for optional repos and other cloud providers only get the back repo/package set. --Noah -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: