| Newsgroups |
gmane.comp.sysutils.cfengine.general |
| Message-ID |
<[email protected]> |
Craig,
Many thanks.
I've tweaked the machine to produce coredumps.
And because this machine was basically "@minimal_environment" I also added
loads of extra RPMs, including even "@development", on the speculative
guess that it might have been the absence of something. But it still
coredumps (which is at least consistent).
I have a core dump (and can produce more), and "cf-support" has produced
what looks like a decent tar.gz. It says "Please send <long-tarfile_anme>
to CFEngine support staff." How can I do that, please?
Meanwhile I had a quick look at the gdb backtrace. It is:
-----------------------------------------------------------
(gdb) backtrace
#0 0x0000000000000000 in ?? ()
#1 0x00007f4852579b75 in PromiseRuntimeHash ()
from /var/cfengine/lib/libpromises.so.3
#2 0x00007f4852579eb0 in AcquireLock ()
from /var/cfengine/lib/libpromises.so.3
#3 0x000000000042097c in VerifyMethod ()
#4 0x0000000000420ee7 in VerifyMethodsPromise ()
#5 0x000000000040e254 in KeepAgentPromise ()
#6 0x00007f4852566663 in ExpandPromise ()
from /var/cfengine/lib/libpromises.so.3
#7 0x000000000040f3d9 in ScheduleAgentOperations ()
#8 0x0000000000410594 in main ()
-----------------------------------------------------------
-- David Lee
On Friday, 24 March 2023 at 18:59:48 UTC [email protected] wrote:
> I did try with a rhel-9 vm and had no issues with 3.21.1 via cf-remote.
> Which other packages did you use? Can you send URLs?
>
> outside the vm, on the host:
> cf-remote install --edition community --clients vagrant@rhel-9
>
> then on the vm:
> sudo su
> cf-agent -IB localhost
> cf-agent -KIf update.cf
> cf-agent -KI
>
> No segfaults sadly. I did notice I have the same version of selinux-policy
> package you mentioned: 34.1.43.1.el9.
>
> Hopefully you can install systemd-coredump and get some backtraces for us
> to examine.
>
> -Craig
>
> On Friday, March 24, 2023 at 1:09:56 PM UTC-5 [email protected]
> wrote:
>
>> 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/5d21b477-5b65-4e0e-92c9-208819f3c3aan%40googlegroups.com.