| Newsgroups |
gmane.comp.sysutils.cfengine.general |
| Message-ID |
<[email protected]> |
No known issues that we are aware of. Can you try enabling core dumps and
running the cf-support tool to collect a backtrace of the fault?
For your system I would recommend installing systemd-coredump.
I will give it a try in a VM and see if I get similar results.
-Craig
On Friday, March 24, 2023 at 6:19:12 AM UTC-5 [email protected]
wrote:
> Craig,
>
> Update: good news and bad news.
>
> Our relatively conservative Satellite is now offering version 34.1.43 of
> selinux-policy. So I have upgraded my test RHEL9 VM to that version (in
> fact a general "yum update" to include other RHEL9 updates on offer). I
> also downloaded the latest nightly builds of both 3.18 and 3.21 community
> edition.
>
> The good news is that these nightly-build RPMs now install cleanly.
>
> The bad news is that "cf-agent --bootstrap=<local-policyhost-cname>"
> segfaults very early. I tried this with four RPMs: 3.18 and 3.21 from
> latest nightly build and also from a nightly build that I happened to have
> to hand from Feb 22/23 (i.e. about a month ago). In all cases it
> segfaults. Here is the end of a typical "--bootstrap" run (with added
> "-d" and "-v"):
>
> -----------------------------------------
> debug: Current umask is 22^M
> verbose: Setting abort classes from ...^M
> verbose: Setting ifelapsed to 0^M
> verbose:
> ----------------------------------------------------------------^M
> verbose: Begin policy/promise evaluation ^M
> verbose:
> ----------------------------------------------------------------^M
> verbose: Using bundlesequence => {"main"}^M
> verbose: B:
> *****************************************************************^M
> verbose: B: BEGIN bundle main^M
> verbose: B:
> *****************************************************************^M
> debug: DeRefCopyPromise(): promiser:'description'^M
> debug: DeRefCopyPromise(): copying constraint: 'string'^M
> verbose: V: Computing value of 'description'^M
> debug: Evaluating vars promise: description^M
> debug: V: 'description' => 'NONE'^M
> verbose: A: Promise was KEPT^M
> verbose: P: END meta promise (description)^M
> debug: Evaluating vars promise: description^M
> debug: DeRefCopyPromise(): promiser:'Check Keys'^M
> debug: DeRefCopyPromise(): copying bundle:
> 'failsafe_cfe_internal_checkkeys'^M
> debug: DeRefCopyPromise(): copying constraint: 'comment'^M
> Segmentation fault^M
> -----------------------------------------
>
> I also tried (speculatively!) with SELinux permissive (rather than our
> usual enforcing), but that doesn't help the segfault.
>
> Any known issues?
>
> -- David Lee
>
>
>
> On Thursday, 23 February 2023 at 20:02:46 UTC [email protected]
> wrote:
>
>> Much gratitude to you David for testing things out and getting back.
>>
>> Yes, I hear you about latest versus stable and agree.
>>
>> I will do some research to see if we can make our packages a bit more
>> adaptable. SELinux is the real culprit here I think. Either that or our
>> understanding of how to work with it and packaging.
>>
>> Be well, and hope to get back to you soon,
>> Craig
>>
>> On Thursday, February 23, 2023 at 8:17:44 AM UTC-6
>> [email protected] wrote:
>>
>>> Craig,
>>>
>>> Many thanks for the update. Apologies for the delay in acknowledging (I
>>> do a three day week, usually Wed-Fri).
>>>
>>> I've successfully grabbed the 3.18 and 3.21 RPMs from the "nightly" URL
>>> at the end of your email. Thanks.
>>>
>>> With both versions, my "yum install ...." from that file fails quickly
>>> at the "selinux" point that you mention. Yet a subsequent "yum upgrade"
>>> says "Nothing to do. Complete!" A "yum list" reports that our Satellite
>>> channel is at version "34.1.29-1.el9_0.2".
>>>
>>> Is there a particular reason why your RPMs requires the very, very
>>> latest version of that RH "selinux-policy" RPM? Is there some unavoidably
>>> essential feature of it that is absent at 34.1.29?
>>>
>>> I know that developers love working on the very latest things. But
>>> could I, as an end-user (not developer) of the product, suggest that the
>>> release environment (as perhaps distinct from the development environment)
>>> that is packaging these RPMs be accepting of somewhat earlier versions?
>>> End-user sites, such as us, often have very good reasons (local stability,
>>> etc.) for deliberately being a little behind latest releases. And if we're
>>> having that trouble, doubtless other sites, too, will also encounter it.
>>>
>>> Happy to continue that particular conversation off-list if you wish.
>>> Use my Diamond email address for that.
>>>
>>> Anyway, if you could package with a more flexible/generous dependency,
>>> that would be useful.
>>>
>>> All the best.
>>>
>>> -- David Lee
>>>
>>>
>>> On Friday, 17 February 2023 at 15:44:30 UTC [email protected]
>>> wrote:
>>>
>>>> Hi David,
>>>>
>>>> We have just fixed up our nightly community packages for rhel8 and
>>>> rhel9 and these builds should ierrornclude the fix for selinux policy
>>>> module import during install.
>>>>
>>>> If the selinux policy included in our package is newer than the version
>>>> in the OS you will get an error with instructions
>>>> <https://github.com/cfengine/buildscripts/blob/master/packaging/common/cfengine-non-hub/postinstall.sh#L121-L150>
>>>> on what to do. The source for the selinux policy is included in the RPM now
>>>> so you can build it custom for your system if need be.
>>>>
>>>> For example, on an rhel 9 system that is not upgraded I get:
>>>>
>>>> Error:
>>>> Problem: conflicting requests
>>>> - nothing provides selinux-policy >= 34.1.43 needed by
>>>> cfengine-community-3.21.1a.921398ce3-25452.el9.x86_64
>>>>
>>>> The best option is to upgrade your system which should ensure that your
>>>> selinux and kernel are the same or newer than the policy included in our
>>>> package.
>>>>
>>>> cf-remote can show you the package URL:
>>>>
>>>> $ cf-remote --version 3.21.x list --edition community el9 Available
>>>> releases: master, 3.21.x, 3.21.0, 3.18.x, 3.18.3, 3.18.2, 3.18.1, 3.18.0
>>>> Using 3.21.x LTS:
>>>> http://buildcache.cfengine.com/packages/testing-pr/jenkins-community-nightly-3.21.x-42/PACKAGES_x86_64_linux_redhat_9/cfengine-community-3.21.1a.921398ce3-25452.el9.x86_64.rpm
>>>>
>>>> or can install if the host has nopasswd sudo access:
>>>>
>>>> $ cf-remote --version 3.21.x install --edition community --clients
>>>> vagrant@rhel-9
>>>>
>>>> Also available on the website:
>>>> https://cfengine.com/downloads/cfengine-community-nightly/
>>>>
>>>> Let us know how it goes!
>>>> -Craig
>>>>
>>>> On Thursday, January 19, 2023 at 9:31:49 AM UTC-6
>>>> [email protected] wrote:
>>>>
>>>>> Craig,
>>>>>
>>>>> Many thanks. In this context, we are simply end-users. We'd like to
>>>>> get RHEL9 prepared, but we can probably wait until you have an RPM
>>>>> (assuming the next few weeks). That said, when you believe your RPM is in
>>>>> a reasonable beta (or release-candidate or pre-release) state let me know
>>>>> and I can give it a try and report back. This would apply both to 3.21 and
>>>>> to 3.18 backport.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> -- David Lee
>>>>>
>>>>> On Friday, 6 January 2023 at 21:30:47 UTC [email protected]
>>>>> wrote:
>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>> I am working on this right now and have worked up a solution.
>>>>>>
>>>>>> Essentially our compiled cfengine-enterprise.pp selinux policy is
>>>>>> compiled to a certain policydb version.
>>>>>>
>>>>>> Probably the best work-around for you right now is to re-compile the
>>>>>> policy yourself from sources in the cfengine core repository.
>>>>>>
>>>>>> $ git clone https://github.com/cfengine/core --depth 1 # or use what
>>>>>> you have already checked out
>>>>>> $ sudo yum install selinux-policy-devel
>>>>>> $ cd core/misc/selinux
>>>>>> $ make -f /usr/share/selinux/devel/Makefile -j1
>>>>>> $ sudo semodule -n -i cfengine-enterprise.pp
>>>>>>
>>>>>> See this pair of PRs for core and buildscripts for my pretty close to
>>>>>> done work in progress for solving this in the installer package:
>>>>>>
>>>>>> https://github.com/cfengine/core/pull/5146
>>>>>> https://github.com/cfengine/buildscripts/pull/1187
>>>>>>
>>>>>> Where I have added a Requires for the version of selinux-policy
>>>>>> package that we use when we build the package and similar work-around notes
>>>>>> as above if the module fails to import.
>>>>>>
>>>>>> Cheers,
>>>>>> Craig
>>>>>>
>>>>>>
>>>>>> On Friday, January 6, 2023 at 12:37:49 PM UTC-6 Nick Anderson wrote:
>>>>>>
>>>>>>> "t.d…@servicemusic.org.uk" <[email protected]> writes:
>>>>>>>
>>>>>>> I observe that the community download page
>>>>>>> https://cfengine.com/downloads/cfengine-community/ offers
>>>>>>> RHEL9/CentOS9 for 3.21.0 LTS (good) but not for 3.18.3 LTS. If 3.18.3 now
>>>>>>> supports RHEL9, could that page be investigated and rectified, please?
>>>>>>> (Because of "rxdirs" I'd rather avoid 3.21 for the moment… there's plenty
>>>>>>> of other catch-up for me to do prior to that! So if a 3.18/RHEL9 RPM s
>>>>>>> available that would be great.)
>>>>>>>
>>>>>>> That's because we have not released a 3.18 package for el9. The
>>>>>>> 3.18.x output I showed you was from nightly builds, so 3.18.4 (hopefully).
>>>>>>>
>>>>>>> Meanwhile: a possible "semodule" bug report for 3.21 on RHEL9.
>>>>>>> Latest OS (yum upgrade); I had installed before Christmas. I hit the
>>>>>>> problem just now; then did a yum upgrade (lots of packages upgraded), then
>>>>>>> rebooted, then tried again. Problem still there. This is the latest::
>>>>>>>
>>>>>>> Yeah, we have noticed some issues with el9 and needing to be updated
>>>>>>> in order for the package to install. We are still looking at how to best
>>>>>>> address it.
>>>>>>>
>>>>>>> – Nick Anderson | Doer of Things | (+1) 785-550-1767
>>>>>>> <(785)%20550-1767> | https://northern.tech
>>>>>>>
>>>>>>
--
You received this message because you are subscribed to the Google Groups "help-cfengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion on the web visit https://groups.google.com/d/msgid/help-cfengine/bb8259da-6f17-4749-9fb4-8ed74a053eb3n%40googlegroups.com.