Facter fact length?

[bg]

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.  

[devzero2000]

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 <green...@gmail.com>:

> --
> 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...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>

--
Inviato dal mio dispositivo mobile

[bg]

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 <green...@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...@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 <green...@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...@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 <green...@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...@googlegroups.com.
> To unsubscribe from this group, send email to

> puppet-users+unsubscribe@googlegroups.com.

[Denmat]

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

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...@googlegroups.com.

To unsubscribe from this group, send email to puppet-users...@googlegroups.com.

[bg]

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?).