[Puppet Users] Cloud init configuration management with Puppet
I thought this would be super easy but hit a road block (at least in terms
of an elegance solution - yes I know how to use exec type with sed and grep
but that feels a bit to much like a workaround)
My requirements is for a file at /etc/cloud/cloud.cfg that looks like this:
users:
- default
- name: ec2-user
primary-group: users
groups: users
lock-passwd: false
sudo: ['ALL=(ALL) NOPASSWD:ALL']
disable_root: 1
ssh_pwauth: 0
to be changed to this (The only change is highlighted below in yellow...
ssh_pwauthfrom 0 to 1):
users:
- default
- name: ec2-user
primary-group: users
groups: users
lock-passwd: false
sudo: ['ALL=(ALL) NOPASSWD:ALL']
disable_root: 1
ssh_pwauth: 1
The file is pre-existing in the AMI and is not created by Puppet. If
something like this worked, I would be super happy but, it doesn't.
augeas { enable-ssh-pwauth :
changes = [set /files/etc/ssh/sshd_config/ssh_pwauth 1,]
}
I've tried
Augeas 1.0.0 and 1.4.0 on OracleLinux 6.6... Neither seem to work
Is Yaml-like lens in augeas even supported? And, if not, is there any other
way I can solve this without grep + sed exec type pattern?
Thoughts?
--
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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/b6d54be7-a3fe-41cc-95c1-ad9e034f9a04%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Cloud init configuration management with Puppet
I believe you're looking at it from the wrong view point if you're
trying to simply use an existing AMI and not for the creation of a new
AMI to load.
The cloud-init configuration can be manipulated using the user-data
passed to the EC2 instance on initialization just as you can trigger the
puppet installation. I suggest you check out the cloud-init
documentation for the version installed on your AMI.
On 23.08.2015 22:21, Craig Barr wrote:
I thought this would be super easy but hit a road block (at least in
terms of an elegance solution - yes I know how to use exec type with
sed and grep but that feels a bit to much like a workaround)
My requirements is for a file at /etc/cloud/cloud.cfg that looks like
this:
users:
- default
- name: ec2-user
primary-group: users
groups: users
lock-passwd: false
sudo: [ALL=(ALL) NOPASSWD:ALL]
disable_root: 1
ssh_pwauth: 0
to be changed to this (The only change is highlighted below in
yellow... ssh_pwauthfrom 0 to 1):
users:
- default
- name: ec2-user
primary-group: users
groups: users
lock-passwd: false
sudo: [ALL=(ALL) NOPASSWD:ALL]
disable_root: 1
ssh_pwauth: 1
The file is pre-existing in the AMI and is not created by Puppet. If
something like this worked, I would be super happy but, it
doesnt.
augeas { enable-ssh-pwauth :
changes = [set /files/etc/ssh/sshd_config/ssh_pwauth 1,]
}
Ive tried
Augeas 1.0.0 and 1.4.0 on OracleLinux 6.6... Neither seem to work
Is Yaml-like lens in augeas even supported? And, if not, is there any
other way I can solve this without grep + sed exec type pattern?
Thoughts?
--
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 puppet-users+unsubscr...@googlegroups.com [1].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/b6d54be7-a3fe-41cc-95c1-ad9e034f9a04%40googlegroups.com
[2].
For more options, visit https://groups.google.com/d/optout [3].
Links:
--
[1] mailto:puppet-users+unsubscr...@googlegroups.com
[2]
https://groups.google.com/d/msgid/puppet-users/b6d54be7-a3fe-41cc-95c1-ad9e034f9a04%40googlegroups.com?utm_medium=emailutm_source=footer
[3] https://groups.google.com/d/optout
--
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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/eb1c6c00a0ea2757efba99c0781a5b20%40undergrid.net.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] keep changing owner
Thanks .. that module did changed the ownership of libdir. Regards, Patrick. Op maandag 17 augustus 2015 17:55:51 UTC+2 schreef Josh Cooper: Hi Patrick, On Thu, Aug 13, 2015 at 6:10 AM, Patrick G. pgh...@gmail.com javascript: wrote: Hi, When running puppet agent -t I get Notice: /File[/var/lib/puppet/lib]/owner: owner changed 'puppet' to 'root' Notice: /File[/var/lib/puppet/lib]/group: group changed 'puppet' to 'root' And then Notice: /Stage[main]/My_fw/File[/var/lib/puppet/lib]/owner: owner changed 'root' to 'puppet' Notice: /Stage[main]/My_fw/File[/var/lib/puppet/lib]/group: group changed 'root' to 'puppet' For a lot of files. Why? Puppet will manage file permissions for its internal settings that are file/directories, e.g. Puppet[:libdir] is /var/lib/puppet/lib. It appears you have a module that is trying to manage permissions on that directory as well, and they disagree about what the desired state should be. I would remove the /var/lib/puppet/lib resource from your My_fw module (and any other Puppet settings-related file/directory). Regards, Patrick. -- 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 puppet-users...@googlegroups.com javascript:. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/1af6a1e5-4125-457c-a0ec-5b0a139042df%40googlegroups.com https://groups.google.com/d/msgid/puppet-users/1af6a1e5-4125-457c-a0ec-5b0a139042df%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. Josh -- Josh Cooper Developer, Puppet Labs -- 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 puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/4d71c7b0-bff4-4f53-84bf-87d01ef0ceb1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] how were your puppet 3-4 upgrades?
On 8/24/15 12:59 PM, Christopher Wood wrote: (Although I may dump/restore the data via puppetdb since that's the actual api to the data, we do not log in via PostgreSQL.) Others can speak to the rest of the plan, but just to clarify in case I'm understanding you right: the PuppetDB import/export tools are not intended to work across different versions of PDB, so an export of 2.x data will not be importable on 3.x. I can see that this is a hole in our documentation, which I'll fix up in a minute. Instead, the necessary data migrations will be handled by the upgrade itself on the first startup of PuppetDB 3.0. Taking a pg_dump or PuppetDB export for a backup prior to the upgrade is still a prudent thing to do in case a downgrade is required, but that will only allow you to restore from the version you came from (possibly earlier ones too in the export case, but only by happenstance). For your use case I'd recommend pg_dump over PuppetDB export since it'll run a lot faster, but either one will get the job done. Wyatt -- 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 puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/55DB8009.6080300%40puppetlabs.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] how were your puppet 3-4 upgrades?
I am not seeing a large amount of blog entries complaining about this upgrade, how has that gone for you? Is there anything you found particularly painful? Would you have done anything different in retrospect? I'm staring down a 3.7.2 - 4.2.1 upgrade and after reading a number of docs the back-of-the-envelope optimal upgrade path is as follows. If any of you have commentary I am quite interested, otherwise I will try it and see what happens. I feel like this might be more time-consuming work but less brainpower effort than just yanking everything to 4.2. 1) rpms up to puppet 3.8 PostgreSQL 8.4 to 9.4 PuppetDB 2.2.2 to 2.3.7 (puppetdb-terminus from 2.2.2 to 2.3.7) Puppet 3.7.2 to 3.8.2 2) enable the future parser 3) replace puppet 3.8.2, passenger 5 with puppetserver 1.1.1 4) replace puppetserver 1.1.1 with puppetserver 2.1.1 5) upgrade PuppetDB from 2.3.7 to 3.0.2 6) use the puppetlabs-puppet_agent forge module to upgrade agents to 4.2.1 My reading: https://docs.puppetlabs.com/puppet/latest/reference/ https://docs.puppetlabs.com/puppet/4.2/reference/upgrade_major_pre.html https://docs.puppetlabs.com/puppet/4.2/reference/upgrade_major_server.html https://docs.puppetlabs.com/puppet/4.2/reference/upgrade_major_agent.html https://docs.puppetlabs.com/puppet/4.2/reference/upgrade_major_post.html https://forge.puppetlabs.com/puppetlabs/puppet_agent https://docs.puppetlabs.com/puppetdb/2.3/upgrade.html http://docs.puppetlabs.com/puppetdb/3.0/upgrade.html http://www.postgresql.org/docs/9.4/static/upgrading.html (Although I may dump/restore the data via puppetdb since that's the actual api to the data, we do not log in via PostgreSQL.) -- 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 puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/20150824195938.GA28076%40iniquitous.heresiarch.ca. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] how were your puppet 3-4 upgrades?
I will be snapshotting the VM to lower the rollback effort there, but good point at that. Otherwise that saves me a bunch of preprod fiddling, thank you. On Mon, Aug 24, 2015 at 01:35:21PM -0700, Wyatt Alt wrote: On 8/24/15 12:59 PM, Christopher Wood wrote: (Although I may dump/restore the data via puppetdb since that's the actual api to the data, we do not log in via PostgreSQL.) Others can speak to the rest of the plan, but just to clarify in case I'm understanding you right: the PuppetDB import/export tools are not intended to work across different versions of PDB, so an export of 2.x data will not be importable on 3.x. I can see that this is a hole in our documentation, which I'll fix up in a minute. Instead, the necessary data migrations will be handled by the upgrade itself on the first startup of PuppetDB 3.0. Taking a pg_dump or PuppetDB export for a backup prior to the upgrade is still a prudent thing to do in case a downgrade is required, but that will only allow you to restore from the version you came from (possibly earlier ones too in the export case, but only by happenstance). For your use case I'd recommend pg_dump over PuppetDB export since it'll run a lot faster, but either one will get the job done. Wyatt -- 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 puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/55DB8009.6080300%40puppetlabs.com. For more options, visit https://groups.google.com/d/optout. -- 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 puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/20150824222044.GA28904%40iniquitous.heresiarch.ca. For more options, visit https://groups.google.com/d/optout.
