Yes, you are right. And, > puppet agent --enable ; puppet agent --test --noop --show_diff ; puppet agent --disable
was handy! Thanks, Robin. On Mon, Feb 10, 2025 at 1:18 AM 'Robin Lee Powell' via Puppet Users < [email protected]> wrote: > > > On Sat, Feb 08, 2025 at 10:54:15AM -0800, subin ks wrote: > > Hi, > > > > *Scenario*: > > We have Puppet 6.14.0 in our infra. Below is the status of puppet agent > on > > one of our Apache HTTPD servers: > > > > *$ ps aux|grep puppetroot 1282 0.0 1.6 292500 63056 ? Ssl > > > 2024 6:48 /opt/puppetlabs/puppet/bin/ruby > > /opt/puppetlabs/puppet/bin/puppet agent --no-daemonize* > > > > > > > > > > > > > > > > > > > > > > *$ systemctl status puppet● puppet.service - Puppet agent Loaded: > loaded > > (/lib/systemd/system/puppet.service; enabled; vendor preset: enabled) > > Active: active (running) since Mon 2024-07-15 23:47:20 -05; 6 months 24 > > days ago Main PID: 1282 (puppet) Tasks: 2 Memory: 71.9M CPU: > 6min > > 48.210s CGroup: /system.slice/puppet.service └─1282 > > /opt/puppetlabs/puppet/bin/ruby /opt/puppetlabs/puppet/bin/puppet agent > > --no-daemonize* > > > > > > *$ grep runinterval /etc/puppetlabs/puppet/puppet.confruninterval = 20m* > > > > We do our config management locally via Git. When we need a change, we > make > > changes locally, push it to remote Puppet master repo, raise a PR for > > approval, and merge it to 'master' branch. Once merged to the master, > the > > config changes are then pulled by puppet agents on Apache HTTPD servers. > > > > *Issue*: > > Due to an emergency, we had to disable Puppet (puppet agent --disable) > on > > Apache servers and make changes directly by hand in to Apache's configs; > > quite a lot of changes went in. > > > > Now, the config-management code in Git is out of sync with the live > configs > > on servers. Because of this we can't enable puppet agent on the Apache > > servers. > > > > *Aim:* > > We need to be able to enable Puppet agent on the Apache servers, but > only > > after bringing our code in Git upto speed with changes that went into > the > > servers manually. The plan of action: > > > > 1. Stop Puppet using `systemctl stop puppet`. > > 2. Run `puppet agent --test --noop --show_diff`, note the drift. > > 3. Commit code into Git to bridge the drift. > > 4. Repeat 2 > 3 until `puppet agent --test --noop --show_diff` shows 'no > > changes'. > > 5. Start Puppet using `systemctl start puppet`. > > 6. Enable Puppet `puppet agent --enable`. > > > > *Question:* > > > > 1. Because runinterval is set to 20m, will Puppet agent run in between > even > > after `systemctl stop puppet`? > > Only if you have a cron job set up. > > Like, once you stop puppet, check to make sure that no puppet processes > are running at all, and check for cron jobs, and if you don't find any, > there's nothing that should magically restart puppet at that point. > > Having said that, you can also, like, instead of doing `puppet agent > --test --noop --show_diff`, do `puppet agent --enable ; puppet agent --test > --noop --show_diff ; puppet agent --disable "still working on it"`. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/puppet-users/Z6kGbnu7KvCPP0sE%40stodi.digitalkingdom.org > . > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/puppet-users/CA%2BX%3DymBA7Lo9K7XA62G2Pod7J1Wxu819q6q-C9LtVkdWS3v%3D5A%40mail.gmail.com.
