Fedora has issued an advisory today (November 28): https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/62SELE7EKVKZL4GABFMVYMIIUZ7FPEF7/ The issues are fixed upstream in 7.12.1. Mageia 8 is also affected.
Whiteboard: (none) => MGA8TOOStatus comment: (none) => Fixed upstream in 7.12.1
New version pushed in cauldron
Version: Cauldron => 8Whiteboard: MGA8TOO => (none)CC: (none) => mageia
(In reply to Nicolas Lécureuil from comment #1) > New version pushed in cauldron Thanks, wil you push it to stable, too?
CC: (none) => bruno, guillomovitch, marja11, tmbAssignee: bugsquad => pkg-bugs
No, this is a big jump. I patched for one CVE, i will try the second one
(In reply to Nicolas Lécureuil from comment #3) > No, this is a big jump. > > I patched for one CVE, i will try the second one Thanks. Assigning to you then, since you're currently working on it, and setting status to ASSIGNED to keep others from duplicating your work. Feel free to revert that.
Status: NEW => ASSIGNEDAssignee: pkg-bugs => mageia
Should be fixed in mga8: src: - puppet-7.1.0-1.1.mga8
Status comment: Fixed upstream in 7.12.1 => (none)Assignee: mageia => qa-bugs
puppet-server-7.1.0-1.1.mga8 puppet-7.1.0-1.1.mga8 from puppet-7.1.0-1.1.mga8.src.rpm
MGA8-64 Plasma on Lenovo B50 in Dutch No installation issues. Reading thru wiki and other previous updates, but to me it's all a big mess. I even don't get what purpose this should serve. Anyway, trying to get the services started, but no way.... # systemctl start puppet [root@mach5 ~]# systemctl -l status puppet ● puppet.service - Puppet agent Loaded: loaded (/usr/lib/systemd/system/puppet.service; disabled; vendor preset: disabled) Active: failed (Result: exit-code) since Mon 2021-12-20 15:13:28 CET; 2s ago Process: 31101 ExecStart=/usr/bin/puppet agent ${PUPPET_EXTRA_OPTS} --no-daemonize (code=exited, status=1/FAILURE) Main PID: 31101 (code=exited, status=1/FAILURE) CPU: 273ms dec 20 15:13:27 mach5.hviaene.thuis systemd[1]: Started Puppet agent. dec 20 15:13:28 mach5.hviaene.thuis puppet[31101]: cannot load such file -- concurrent dec 20 15:13:28 mach5.hviaene.thuis systemd[1]: puppet.service: Main process exited, code=exited, status=1/FAILURE dec 20 15:13:28 mach5.hviaene.thuis systemd[1]: puppet.service: Failed with result 'exit-code'. and # systemctl start puppetmaster [root@mach5 ~]# systemctl -l status puppetmaster ● puppetmaster.service - Puppet master Loaded: loaded (/usr/lib/systemd/system/puppetmaster.service; disabled; vendor preset: disabled) Active: failed (Result: exit-code) since Mon 2021-12-20 15:17:50 CET; 9s ago Process: 31293 ExecStart=/usr/bin/puppet master ${PUPPETMASTER_EXTRA_OPTS} --no-daemonize (code=exited, status=1/FAILURE) Main PID: 31293 (code=exited, status=1/FAILURE) CPU: 237ms dec 20 15:17:50 mach5.hviaene.thuis systemd[1]: Started Puppet master. dec 20 15:17:50 mach5.hviaene.thuis puppet[31293]: cannot load such file -- concurrent dec 20 15:17:50 mach5.hviaene.thuis systemd[1]: puppetmaster.service: Main process exited, code=exited, status=1/FAILURE dec 20 15:17:50 mach5.hviaene.thuis systemd[1]: puppetmaster.service: Failed with result 'exit-code'.
CC: (none) => herman.viaene
Yeah, this is a tough nut to crack Herman. Spent time yesterday trying to get to grips with it. All the beginner's guides on-line hurl information at you without any hand-holding, all assuming that they are talking to "dev-ops". It should be simple to use once you get the hang of it but the real trouble is getting to first base.
CC: (none) => tarazed25
Installed the updates. $ id puppet uid=964(puppet) gid=953(puppet) groups=953(puppet) $ id uid=1000(lcl) gid=1000(lcl) groups=1000(lcl),81(audio),953(puppet),954(vboxusers),988(realtime) Tried enabling and starting the puppet server with the same failure as before. $ cd /etc/puppetlabs $ tree . . ├── code │ └── environments │ └── production │ ├── manifests │ └── modules ├── puppet │ ├── fileserver.conf │ ├── hiera.yaml │ └── puppet.conf └── puppetserver The config file is one added earlier from an old qa archive. $ puppet --version cannot load such file -- concurrent $ puppet cannot load such file -- concurrent $ irb irb(main):001:0> require 'puppet/util/command_line' Traceback (most recent call last): 16: from (irb):1 15: from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:92:in `require' 14: from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:92:in `require' 13: from /usr/share/ruby/vendor_ruby/puppet/util/command_line.rb:12:in `<top (required)>' 12: from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:92:in `require' 11: from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:92:in `require' 10: from /usr/share/ruby/vendor_ruby/puppet.rb:42:in `<top (required)>' 9: from /usr/share/ruby/vendor_ruby/puppet.rb:45:in `<module:Puppet>' 8: from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:92:in `require' 7: from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:92:in `require' 6: from /usr/share/ruby/vendor_ruby/puppet/context.rb:1:in `<top (required)>' 5: from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:92:in `require' 4: from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:92:in `require' 3: from /usr/share/ruby/vendor_ruby/puppet/thread_local.rb:1:in `<top (required)>' 2: from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:92:in `require' 1: from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:92:in `require' LoadError (cannot load such file -- concurrent) irb(main):002:0> exit This from the bundled code.
/usr/share/ruby/vendor_ruby/puppet/concurrent $ ls lock.rb synchronized.rb thread_local_singleton.rb
Maybe it is looking for this: $ locate concurrent.rb /usr/share/ruby/vendor_ruby/puppet/concurrent.rb
Keywords: (none) => feedback
# pwd /usr/share/ruby/vendor_ruby/puppet # cat concurrent.rb module Puppet::Concurrent end Looks like a placeholder or something, maybe for methods etc. defined elsewhere. Perhaps the file is in the wrong place or the path is incomplete.
Performed a trace on `puppet --version` More than 11K lines. openat(AT_FDCWD, "/usr/share/ruby/vendor_ruby/puppet/version.rb", O_RDONLY|O_NONBLOCK|O_CLOEXEC) = 5 fstat(5, {st_mode=S_IFREG|0644, st_size=3719, ...}) = 0 close(5) = 0 getuid() = 1000 geteuid() = 1000 getgid() = 1000 getegid() = 1000 openat(AT_FDCWD, "/usr/share/ruby/vendor_ruby/puppet/version.rb", O_RDONLY|O_NONBLOCK|O_CLOEXEC) = 5 fcntl(5, F_SETFL, O_RDONLY) = 0 fstat(5, {st_mode=S_IFREG|0644, st_size=3719, ...}) = 0 ioctl(5, TCGETS, 0x7fffe9128090) = -1 ENOTTY (Inappropriate ioctl for device) ................ openat(AT_FDCWD, "/usr/share/ruby/vendor_ruby/facter/version.rb", O_RDONLY|O_NONBLOCK|O_CLOEXEC) = 5 fcntl(5, F_SETFL, O_RDONLY) = 0 fstat(5, {st_mode=S_IFREG|0644, st_size=3344, ...}) = 0 ioctl(5, TCGETS, 0x7fffe9127c50) = -1 ENOTTY (Inappropriate ioctl for device) ...... There were searches in multiples places for concurrent.rb including semantic_puppet in the gems tree but not vendor_ruby/puppet but did find command_line.rb in vendor_ruby/puppet/util/ and other files like vendor_ruby/puppet.rb, version.rb and puppet/concurrent/synchronized.rb. There were 96 attempts to find it but it missed out vendor_ruby/puppet/.
Had a look at Cauldron but could get no further forward with understanding what is going on. $ rpm -q puppet puppet-7.12.1-1.mga9 $ puppet --version /home/lcl/.gem/ruby/gems/puppet-7.13.1/lib/puppet/file_system/uniquefile.rb:17:in `<top (required)>': Could not autoload puppet/indirector/file_metadata/selector: superclass mismatch for class Uniquefile (Puppet::Error) Version mismatch because testing version already used in mga8. $ ll .gem total 12 -rw------- 1 lcl lcl 56 May 24 2020 credentials drwxr-xr-x 9 lcl lcl 4096 Nov 7 2019 ruby/ Running as root in Cauldron shows up the "concurrent" problem again. # puppet --version cannot load such file -- concurrent # ll .gem total 4 drwxr-xr-x 3 root root 4096 Jan 17 2021 specs/
The puppet package is just lacking a few dependencies: - ruby-concurrent-ruby - ruby-racc - ruby-deep_merge
And maybe some other(s)? $ puppet --version ..... 1: from /usr/share/ruby/vendor_ruby/puppet/util.rb:344:in `path_to_uri' /usr/share/ruby/vendor_ruby/puppet/util.rb:476:in `uri_encode': undefined method `escape' for URI:Module (NoMethodError)
Have just had another look at puppet and found that it at least responds correctly to the version enquiry before the update. After the update: $ puppet --version 7.13.1 $ rpm -q puppet puppet-7.1.0-1.1.mga8 Could not start the puppet service though. $ sudo systemctl enable puppet $ sudo systemctl start puppet $ sudo systemctl status puppet ● puppet.service - Puppet agent Loaded: loaded (/usr/lib/systemd/system/puppet.service; enabled; vendor pre> Active: failed (Result: exit-code) since Thu 2022-03-10 18:43:58 GMT; 9s ago Process: 173032 ExecStart=/usr/bin/puppet agent ${PUPPET_EXTRA_OPTS} --no-da> Main PID: 173032 (code=exited, status=1/FAILURE) CPU: 486ms Mar 10 18:43:58 difda systemd[1]: Started Puppet agent. Mar 10 18:43:58 difda puppet[173032]: Error: Could not prepare for execution: Th> Mar 10 18:43:58 difda systemd[1]: puppet.service: Main process exited, code=exit> Mar 10 18:43:58 difda systemd[1]: puppet.service: Failed with result 'exit-code'. /etc/puppetlabs $ ls code/ puppet/ puppetserver/ $ tree . . ├── code │ └── environments │ └── production │ ├── manifests │ └── modules ├── puppet │ ├── fileserver.conf │ ├── hiera.yaml │ └── puppet.conf └── puppetserver
# systemctl enable puppetmaster Created symlink /etc/systemd/system/multi-user.target.wants/puppetmaster.service → /usr/lib/systemd/system/puppetmaster.service. # systemctl start puppetmaster # systemctl status puppetmaster ● puppetmaster.service - Puppet master Loaded: loaded (/usr/lib/systemd/system/puppetmaster.service; enabled; vend> Active: failed (Result: exit-code) since Thu 2022-03-10 18:53:17 GMT; 5s ago Process: 241401 ExecStart=/usr/bin/puppet master ${PUPPETMASTER_EXTRA_OPTS} > Main PID: 241401 (code=exited, status=1/FAILURE) CPU: 452ms Mar 10 18:53:16 difda systemd[1]: Started Puppet master. Mar 10 18:53:17 difda puppet[241401]: Error: Unknown Puppet subcommand 'master' Mar 10 18:53:17 difda puppet[241401]: See 'puppet help' for help on available pu> Mar 10 18:53:17 difda systemd[1]: puppetmaster.service: Main process exited, cod> Mar 10 18:53:17 difda systemd[1]: puppetmaster.service: Failed with result 'exit> lines 1-12/12 (END
RedHat has issued an advisory for this today (May 4): https://access.redhat.com/errata/RHSA-2022:1708
SUSE has issued an advisory for one of these issues today (September 26): https://lists.suse.com/pipermail/sle-security-updates/2022-September/012354.html
Comment 15 indicates there are missing dependencies, and comment 16 speculates there may be more than that. Over 18 months since Len last looked at this, and still no response to his questions. And this on a critical security update. Mageia 8 goes EOL in a month. Are we going to fix this or not?
CC: (none) => andrewsfarm
URL: (none) => https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/62SELE7EKVKZL4GABFMVYMIIUZ7FPEF7CC: (none) => yvesbrungard
(In reply to Thomas Andrews from comment #21) > Comment 15 indicates there are missing dependencies, and comment 16 > speculates there may be more than that. Over 18 months since Len last looked > at this, and still no response to his questions. And this on a critical > security update. > > Mageia 8 goes EOL in a month. Are we going to fix this or not? I guess not, and now the Mageia 8 EOL date has passed. From what I'm told, puppet is OK in Mageia 9, but the update won't even start in Mageia 8. It can't be sent out in this condition. Removing the feedback flag, and assigning it to Bugsquad, so its status can be re-evaluated.
Assignee: qa-bugs => bugsquadKeywords: feedback => (none)
(In reply to Guillaume Rousse from comment #15) > The puppet package is just lacking a few dependencies: > - ruby-concurrent-ruby > - ruby-racc > - ruby-deep_merge Where did you dig this up? And what do you make of... (In reply to Len Lawrence from comment #16) > And maybe some other(s)? > $ puppet --version > ..... > 1: from /usr/share/ruby/vendor_ruby/puppet/util.rb:344:in `path_to_uri' > /usr/share/ruby/vendor_ruby/puppet/util.rb:476:in `uri_encode': undefined > method `escape' for URI:Module (NoMethodError) Unsure what extra dependancy is indicated by the last error. FWIW, currently for puppet-7.12.1-3.mga9: $ urpmq --requires puppet | grep ruby ruby ruby-semantic_puppet $ urpmq --requires-recursive puppet | grep ruby lib64ruby3.1 ruby ruby-RubyGems ruby-hocon ruby-io-console ruby-irb ruby-json ruby-psych ruby-rdoc ruby-semantic_puppet
Status: ASSIGNED => NEWCC: (none) => lewyssmith
In reply to Lewis Smith in comment #23: All the required ruby elements seem to be in place in Mageia 9. User in puppet group. The puppet server fails to start, every time, even though it appeared to start for mga9 in an earlier invocation. There is a puppet-server package installed but it is still completely unclear how this fits in and how this relates to puppet-master. It is more than a year since I looked at the documentation. Shelving this until 2024. In mga9: $ puppet --version /usr/share/ruby/vendor_ruby/puppet/thread_local.rb:6:in `<top (required)>': uninitialized constant Concurrent::RubyThreadLocalVar (NameError) class Puppet::ThreadLocal < Concurrent::RubyThreadLocalVar ^^^^^^^^^^^^^^^^^^^^ Did you mean? Concurrent::RubyThreadPoolExecutor Note also that earlier mga8 tests were carried out with a different version of ruby, which may be irrelevant. There was a step change from version 2.7 in mga8 to 3.1 in mga9.
Rider to comment 24; `puppet --version` was run in Cauldron not Mageia9, which did not exist at that time.
The current ruby requirements comment 23 do not include those suggested by Guillaume comment 15: - ruby-concurrent-ruby - ruby-racc - ruby-deep_merge Len (for 2024) Do you have these installed? If not, try installing them, and see whether that changes anything.
This system does not have those particular rpms but I do remember installing them for the original tests on Mageia 8. I installed them here but that made no difference but this may not even be the system I was testing on recently. Shall have to retrace my steps when I can get around to it. Thanks.
This has stagnated and needs sorting out. No one packager evident for Puppet, so assigning globally.
Assignee: bugsquad => pkg-bugsCC: lewyssmith => (none)
Suggested advisory: ======================== The updated packages fix missing requires for puppet and fix commands in systemd units. ======================== Updated packages in core/updates_testing: ======================== puppet-7.12.1-3.1.mga9 puppet-server-7.12.1-3.1.mga9 from SRPM: puppet-7.12.1-3.1.mga9.src.rpm
CC: (none) => nicolas.salgueroVersion: 8 => 9Source RPM: puppet-7.1.0-1.mga8.src.rpm => puppet-7.12.1-3.mga9.src.rpmAssignee: pkg-bugs => qa-bugsStatus: NEW => ASSIGNED
Keywords: (none) => advisory
Thanks katnatek. I do have an interest in this but have been seriously 'hors de combat' for the last few weeks.
Mageia9, x64 Installation of the two packages drew in the required dependencies: ruby-hocon ruby-semantic_puppet ruby-deep_merge facter puppet appears as 943 in /etc/group Added user to that group and recycled login to show that user now belongs to puppet group. # systemctl start puppet # systemctl status puppet ● puppet.service - Puppet agent Loaded: loaded (/usr/lib/systemd/system/puppet.service; disabled; preset: > Active: active (running) since Sat 2024-04-06 10:13:02 BST; 18s ago .... systemd[1]: Started puppet.service. Apr 06 10:13:03 yildun puppet-agent[1088532]: Connection to https://puppet:8140/puppet-ca/v1 failed, trying next route: Request to ht> Apr 06 10:13:03 yildun puppet-agent[1088532]: Wrapped exception: Apr 06 10:13:03 yildun puppet-agent[1088532]: Failed to open TCP connection to puppet:8140 getaddrinfo: Name or service not known) .... Opened TCP port 8140 in firewall but that did not help - same failure. Means nothing to me. AFAICS there are no more missing packages.
Do you have a host named puppet for it to connect to?
No, nothing on my local network. That is not anything I know about. Shall see if there is any documentation locally.
That's what the agent was trying to connect to. I guess the puppet-server has a service that you need to run and then put an entry for that host in /etc/hosts, or change the host name it's trying to connect to in the puppet agent configuration.
Looks like you are correct David; there is no HelloWorld introduction to this subject. AFAICS the infrastructure needs to be partially built already on the network before the server can start. Agents need to be seeded to provide the responses the server expects. So this is a lot of work to start with. I am not in a position just now to carry on with it.
CC: guillomovitch => (none)
(In reply to Len Lawrence from comment #35) > Looks like you are correct David; there is no HelloWorld introduction to > this subject. AFAICS the infrastructure needs to be partially built already > on the network before the server can start. Agents need to be seeded to > provide the responses the server expects. So this is a lot of work to start > with. > > I am not in a position just now to carry on with it. And, from bug 18640 comment 7: Puppet is a complex system management tool best described as a "career builder" (wilcal) so all we can do is ensure that it builds and runs. It is written in ruby so you may find it installing ruby packages as well. This system already had those. Quoting an internet site: Open source Puppet helps you describe machine configurations in a declarative language, bring machines to a desired state, and keep them there through automation. Len had a clean install, and the service started, though with an error that looks like it was probably due to lack of user experience. I'm sending this on on that basis. Validating.
Keywords: (none) => validated_updateWhiteboard: (none) => MGA9-64-OKCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2024-0136.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED