FAQ
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.

Search Discussions

  • Devzero2000 at Jul 22, 2012 at 8:05 am
    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.
  • Bg at Jul 24, 2012 at 1:40 pm
    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.
  • Denmat at Jul 24, 2012 at 9:13 pm
    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 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.
  • Bg at Jul 25, 2012 at 1:30 am
    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 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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJul 22, '12 at 12:07a
activeJul 25, '12 at 1:30a
posts5
users3
websitepuppetlabs.com

3 users in discussion

Bg: 3 posts Denmat: 1 post Devzero2000: 1 post

People

Translate

site design / logo © 2022 Grokbase