This is a bit of a leading question, but is there a limitation as far as length/size of facts on a node? I have a need to perform one way sync of user accounts (non-Puppet managed users) on many pairs of servers. Thus far, it''s been done with scripts from primary -> backup server, and has been problematic. I''d like to create a fact that returns user:password_hash pairs, and then ensure those users are present on the backup server. I would guess the largest number of users on a node would be ~100. Any other creative solutions are appreciated, but keep in mind ldap/nis aren''t valid options. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/WVxoEY4gic8J. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Are you sure that exposing a password hash by a fact is a sane thing to do from a security point of view ? Too simple to mont a dictionary attack, isn''t ? 2012/7/22, bg <greenbrian@gmail.com>:> This is a bit of a leading question, but is there a limitation as far as > length/size of facts on a node? > > I have a need to perform one way sync of user accounts (non-Puppet managed > users) on many pairs of servers. Thus far, it''s been done with scripts > from primary -> backup server, and has been problematic. I''d like to create > > a fact that returns user:password_hash pairs, and then ensure those users > are present on the backup server. > I would guess the largest number of users on a node would be ~100. > > Any other creative solutions are appreciated, but keep in mind ldap/nis > aren''t valid options. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/puppet-users/-/WVxoEY4gic8J. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > >-- Inviato dal mio dispositivo mobile -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
How exposed are facts? Are there any means to collect resources from a client that I can make use of? On Sunday, July 22, 2012 3:05:28 AM UTC-5, yersinia.spiros wrote:> > Are you sure that exposing a password hash by a fact is a sane thing > to do from a security point of view ? Too simple to mont a dictionary > attack, isn''t ? > > 2012/7/22, bg <greenbrian@gmail.com>: > > This is a bit of a leading question, but is there a limitation as far as > > length/size of facts on a node? > > > > I have a need to perform one way sync of user accounts (non-Puppet > managed > > users) on many pairs of servers. Thus far, it''s been done with scripts > > from primary -> backup server, and has been problematic. I''d like to > create > > > > a fact that returns user:password_hash pairs, and then ensure those > users > > are present on the backup server. > > I would guess the largest number of users on a node would be ~100. > > > > Any other creative solutions are appreciated, but keep in mind ldap/nis > > aren''t valid options. > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "Puppet Users" group. > > To view this discussion on the web visit > > https://groups.google.com/d/msg/puppet-users/-/WVxoEY4gic8J. > > To post to this group, send email to puppet-users@googlegroups.com. > > To unsubscribe from this group, send email to > > puppet-users+unsubscribe@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/puppet-users?hl=en. > > > > > > -- > Inviato dal mio dispositivo mobile >On Sunday, July 22, 2012 3:05:28 AM UTC-5, yersinia.spiros wrote:> > Are you sure that exposing a password hash by a fact is a sane thing > to do from a security point of view ? Too simple to mont a dictionary > attack, isn''t ? > > 2012/7/22, bg <greenbrian@gmail.com>: > > This is a bit of a leading question, but is there a limitation as far as > > length/size of facts on a node? > > > > I have a need to perform one way sync of user accounts (non-Puppet > managed > > users) on many pairs of servers. Thus far, it''s been done with scripts > > from primary -> backup server, and has been problematic. I''d like to > create > > > > a fact that returns user:password_hash pairs, and then ensure those > users > > are present on the backup server. > > I would guess the largest number of users on a node would be ~100. > > > > Any other creative solutions are appreciated, but keep in mind ldap/nis > > aren''t valid options. > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "Puppet Users" group. > > To view this discussion on the web visit > > https://groups.google.com/d/msg/puppet-users/-/WVxoEY4gic8J. > > To post to this group, send email to puppet-users@googlegroups.com. > > To unsubscribe from this group, send email to > > puppet-users+unsubscribe@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/puppet-users?hl=en. > > > > > > -- > Inviato dal mio dispositivo mobile >On Sunday, July 22, 2012 3:05:28 AM UTC-5, yersinia.spiros wrote:> > Are you sure that exposing a password hash by a fact is a sane thing > to do from a security point of view ? Too simple to mont a dictionary > attack, isn''t ? > > 2012/7/22, bg <greenbrian@gmail.com>: > > This is a bit of a leading question, but is there a limitation as far as > > length/size of facts on a node? > > > > I have a need to perform one way sync of user accounts (non-Puppet > managed > > users) on many pairs of servers. Thus far, it''s been done with scripts > > from primary -> backup server, and has been problematic. I''d like to > create > > > > a fact that returns user:password_hash pairs, and then ensure those > users > > are present on the backup server. > > I would guess the largest number of users on a node would be ~100. > > > > Any other creative solutions are appreciated, but keep in mind ldap/nis > > aren''t valid options. > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "Puppet Users" group. > > To view this discussion on the web visit > > https://groups.google.com/d/msg/puppet-users/-/WVxoEY4gic8J. > > To post to this group, send email to puppet-users@googlegroups.com. > > To unsubscribe from this group, send email to > > puppet-users+unsubscribe@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/puppet-users?hl=en. > > > > > > -- > Inviato dal mio dispositivo mobile >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/jur49cinr64J. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Hi, Coming In late to the conversation so forgive me if I dont get it. You want to do a one way sync (a pull) from the backup server to other nodes? Well I would say just rsync using passphraseless keys into a directory structure split by node name. However if you want to build a new password and shadow file based on facts you will face some issues. Those facts will not only be available to the facter command, but will also be available to puppetdb and reporting. The major problem I see is knowing which password hash is the current one. Someone could change a password on one host and not another - you''d have figure out which is which somehow. Applying the KISS principle I would rsync to different directories and find something else to do - like set up LDAP ;) - or manage user account from the backup server and push them out to the nodes. Cheers, Den On 24/07/2012, at 23:40, bg <greenbrian@gmail.com> wrote:> How exposed are facts? > > Are there any means to collect resources from a client that I can make use of? > > > On Sunday, July 22, 2012 3:05:28 AM UTC-5, yersinia.spiros wrote: > Are you sure that exposing a password hash by a fact is a sane thing > to do from a security point of view ? Too simple to mont a dictionary > attack, isn''t ? > > 2012/7/22, bg <greenbrian@gmail.com>: > > This is a bit of a leading question, but is there a limitation as far as > > length/size of facts on a node? > > > > I have a need to perform one way sync of user accounts (non-Puppet managed > > users) on many pairs of servers. Thus far, it''s been done with scripts > > from primary -> backup server, and has been problematic. I''d like to create > > > > a fact that returns user:password_hash pairs, and then ensure those users > > are present on the backup server. > > I would guess the largest number of users on a node would be ~100. > > > > Any other creative solutions are appreciated, but keep in mind ldap/nis > > aren''t valid options. > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Puppet Users" group. > > To view this discussion on the web visit > > https://groups.google.com/d/msg/puppet-users/-/WVxoEY4gic8J. > > To post to this group, send email to puppet-users@googlegroups.com. > > To unsubscribe from this group, send email to > > puppet-users+unsubscribe@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/puppet-users?hl=en. > > > > > > -- > Inviato dal mio dispositivo mobile > > On Sunday, July 22, 2012 3:05:28 AM UTC-5, yersinia.spiros wrote: > Are you sure that exposing a password hash by a fact is a sane thing > to do from a security point of view ? Too simple to mont a dictionary > attack, isn''t ? > > 2012/7/22, bg <greenbrian@gmail.com>: > > This is a bit of a leading question, but is there a limitation as far as > > length/size of facts on a node? > > > > I have a need to perform one way sync of user accounts (non-Puppet managed > > users) on many pairs of servers. Thus far, it''s been done with scripts > > from primary -> backup server, and has been problematic. I''d like to create > > > > a fact that returns user:password_hash pairs, and then ensure those users > > are present on the backup server. > > I would guess the largest number of users on a node would be ~100. > > > > Any other creative solutions are appreciated, but keep in mind ldap/nis > > aren''t valid options. > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Puppet Users" group. > > To view this discussion on the web visit > > https://groups.google.com/d/msg/puppet-users/-/WVxoEY4gic8J. > > To post to this group, send email to puppet-users@googlegroups.com. > > To unsubscribe from this group, send email to > > puppet-users+unsubscribe@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/puppet-users?hl=en. > > > > > > -- > Inviato dal mio dispositivo mobile > > On Sunday, July 22, 2012 3:05:28 AM UTC-5, yersinia.spiros wrote: > Are you sure that exposing a password hash by a fact is a sane thing > to do from a security point of view ? Too simple to mont a dictionary > attack, isn''t ? > > 2012/7/22, bg <greenbrian@gmail.com>: > > This is a bit of a leading question, but is there a limitation as far as > > length/size of facts on a node? > > > > I have a need to perform one way sync of user accounts (non-Puppet managed > > users) on many pairs of servers. Thus far, it''s been done with scripts > > from primary -> backup server, and has been problematic. I''d like to create > > > > a fact that returns user:password_hash pairs, and then ensure those users > > are present on the backup server. > > I would guess the largest number of users on a node would be ~100. > > > > Any other creative solutions are appreciated, but keep in mind ldap/nis > > aren''t valid options. > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Puppet Users" group. > > To view this discussion on the web visit > > https://groups.google.com/d/msg/puppet-users/-/WVxoEY4gic8J. > > To post to this group, send email to puppet-users@googlegroups.com. > > To unsubscribe from this group, send email to > > puppet-users+unsubscribe@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/puppet-users?hl=en. > > > > > > -- > Inviato dal mio dispositivo mobile > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/jur49cinr64J. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Probably need to clarify a few things. The server relationships are simply production/backup pairs (almost all 1:1, but > 100 of these unique pairings), and it would be a master/slave type relationship, so there wouldn''t be conflicts between production/backup (the application isn''t active/active). I can''t use keys for these accounts, and the accounts on the production server cannot be centrally managed by Puppet. The current system simply has some poorly written scripts that copy accounts from the production server to the backup server. However, I''d rather have the details centralized in Puppet. This really seems to be me trying to work around Puppet not being able to export data (yet?). On Tuesday, July 24, 2012 4:14:23 PM UTC-5, denmat wrote:> > Hi, > > Coming In late to the conversation so forgive me if I dont get it. > > You want to do a one way sync (a pull) from the backup server to other > nodes? Well I would say just rsync using passphraseless keys into a > directory structure split by node name. > > However if you want to build a new password and shadow file based on facts > you will face some issues. Those facts will not only be available to the > facter command, but will also be available to puppetdb and reporting. > > The major problem I see is knowing which password hash is the current one. > Someone could change a password on one host and not another - you''d have > figure out which is which somehow. > > Applying the KISS principle I would rsync to different directories and > find something else to do - like set up LDAP ;) - or manage user account > from the backup server and push them out to the nodes. > > Cheers, > Den > > > On 24/07/2012, at 23:40, bg <greenbrian@gmail.com> wrote: > > How exposed are facts? > > Are there any means to collect resources from a client that I can make use > of? > > > On Sunday, July 22, 2012 3:05:28 AM UTC-5, yersinia.spiros wrote: >> >> Are you sure that exposing a password hash by a fact is a sane thing >> to do from a security point of view ? Too simple to mont a dictionary >> attack, isn''t ? >> >> 2012/7/22, bg <greenbrian@gmail.com>: >> > This is a bit of a leading question, but is there a limitation as far >> as >> > length/size of facts on a node? >> > >> > I have a need to perform one way sync of user accounts (non-Puppet >> managed >> > users) on many pairs of servers. Thus far, it''s been done with scripts >> > from primary -> backup server, and has been problematic. I''d like to >> create >> > >> > a fact that returns user:password_hash pairs, and then ensure those >> users >> > are present on the backup server. >> > I would guess the largest number of users on a node would be ~100. >> > >> > Any other creative solutions are appreciated, but keep in mind ldap/nis >> > aren''t valid options. >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "Puppet Users" group. >> > To view this discussion on the web visit >> > https://groups.google.com/d/msg/puppet-users/-/WVxoEY4gic8J. >> > To post to this group, send email to puppet-users@googlegroups.com. >> > To unsubscribe from this group, send email to >> > puppet-users+unsubscribe@googlegroups.com. >> > For more options, visit this group at >> > http://groups.google.com/group/puppet-users?hl=en. >> > >> > >> >> -- >> Inviato dal mio dispositivo mobile >> > > On Sunday, July 22, 2012 3:05:28 AM UTC-5, yersinia.spiros wrote: >> >> Are you sure that exposing a password hash by a fact is a sane thing >> to do from a security point of view ? Too simple to mont a dictionary >> attack, isn''t ? >> >> 2012/7/22, bg <greenbrian@gmail.com>: >> > This is a bit of a leading question, but is there a limitation as far >> as >> > length/size of facts on a node? >> > >> > I have a need to perform one way sync of user accounts (non-Puppet >> managed >> > users) on many pairs of servers. Thus far, it''s been done with scripts >> > from primary -> backup server, and has been problematic. I''d like to >> create >> > >> > a fact that returns user:password_hash pairs, and then ensure those >> users >> > are present on the backup server. >> > I would guess the largest number of users on a node would be ~100. >> > >> > Any other creative solutions are appreciated, but keep in mind ldap/nis >> > aren''t valid options. >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "Puppet Users" group. >> > To view this discussion on the web visit >> > https://groups.google.com/d/msg/puppet-users/-/WVxoEY4gic8J. >> > To post to this group, send email to puppet-users@googlegroups.com. >> > To unsubscribe from this group, send email to >> > puppet-users+unsubscribe@googlegroups.com. >> > For more options, visit this group at >> > http://groups.google.com/group/puppet-users?hl=en. >> > >> > >> >> -- >> Inviato dal mio dispositivo mobile >> > > On Sunday, July 22, 2012 3:05:28 AM UTC-5, yersinia.spiros wrote: >> >> Are you sure that exposing a password hash by a fact is a sane thing >> to do from a security point of view ? Too simple to mont a dictionary >> attack, isn''t ? >> >> 2012/7/22, bg <greenbrian@gmail.com>: >> > This is a bit of a leading question, but is there a limitation as far >> as >> > length/size of facts on a node? >> > >> > I have a need to perform one way sync of user accounts (non-Puppet >> managed >> > users) on many pairs of servers. Thus far, it''s been done with scripts >> > from primary -> backup server, and has been problematic. I''d like to >> create >> > >> > a fact that returns user:password_hash pairs, and then ensure those >> users >> > are present on the backup server. >> > I would guess the largest number of users on a node would be ~100. >> > >> > Any other creative solutions are appreciated, but keep in mind ldap/nis >> > aren''t valid options. >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "Puppet Users" group. >> > To view this discussion on the web visit >> > https://groups.google.com/d/msg/puppet-users/-/WVxoEY4gic8J. >> > To post to this group, send email to puppet-users@googlegroups.com. >> > To unsubscribe from this group, send email to >> > puppet-users+unsubscribe@googlegroups.com. >> > For more options, visit this group at >> > http://groups.google.com/group/puppet-users?hl=en. >> > >> > >> >> -- >> Inviato dal mio dispositivo mobile >> > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/puppet-users/-/jur49cinr64J. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/05maZKc2zgUJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.