similar to: Best practice for user accounts

Hello, I''m a puppet newbie and I''m having trouble getting my virtual user setup to work. Can someone please tell me what''s wrong with this setup? # virtual.pp # class virtual_users::virtual { @group { "users": gid => "100", ensure => present } @user { "lmoore": password =>

I''m trying to work with Users and the realize function, and it''s driving me batty. Puppet is 0.23.2. My definition looks something like: class virtual_users { @user { fred : uid => 500 ... } @user { derf : uid => 501 ... } } node base-node { include virtual_users } node "testnode.domain.local" inherits base-node { realize User[fred] } puppetd

Hi all, I''m a new puppet user and I''m running into some weirdness around creating users on solaris. (puppet version 0.23.2) The virt_all_users way of managing users seems pretty reasonable, but I don''t see how to deal with user specific groups with that. I have: class virt_all_users { @user { "seph": ensure => "present",

I would like to write up brief tutorial/documentation on how to manage /etc/passwd using puppet. While this may seem pretty straight forward to some...the documentation is not. We have been able to create a manifest that defines all of our users "virtually" and are able to "realize" users and add them to the system(s) running puppetd. Is there a way to simply realize all users

An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20230304/f769686e/attachment.htm>

An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20230304/a3753b6e/attachment-0001.htm>

An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20230305/f943341b/attachment-0001.htm>

Hi everybody! So for non-automated physical/manual application of single specific patterns or sets of puppet patterns on an entirely manual basis, what is best practice and/or where is it described? Meaning what is the way to stop the puppet agent from running automatically and instead require a manual command for puppet to exercise on that node. If it is as simple as puppet apply

Hello folks. I''ve got a problem that I can''t work out the solution to. My base workstation node definition says essentially: node base-workstation { file { etc-sudoers: name => "/etc/sudoers", ... } } This works fine, all of our workstations get a standardised sudoers file. However, I have one user on a workstation who needs a specialised sudoers file.

Hi again, I am using dovecot 2.3.16, along with postfix and a PostgreSQL database for managing virtual accounts. After an initial topic from me about encrypting already existent mail, I could now use some pointers on how to set up the mail-crypt plugin for pure virtual accounts (i.e. that have no matching system users and/or home directories. I hope somebody can clarify a few things that are not

Hi, While puppet creates its own directories for internal stuff (puppetca, state, etc.), there''s a fair bit of latitude given to where things like manifests and uploaded files live. I didn''t get much guidance from the docs when I first set things up so I mostly poked at things until the worked. Take a look at the following and let me know if this looks reasonable; if so, it

What is the best way to manage multiple stanza within a config file? For a splunk configuration file (inputs.conf) I need to manage some thing like [monitor://var/log] blacklist = someRegularExpression whitelist = someOtherRegularExpression [monitor://var/lib/ourApp] There can be multiple monitor stanzas and each may or may not have a whitelist or blacklist. I haven''t found any

Hello! In my puppet configuration I need to get some data from database. Ie.: I''ve got information about my all hosts in db - thier name, mac addresses, ip addresses, what to backup from this host etc. For now it''s just .xml file, but it could be sql db, or ldap directory. Then, using this small "database", I want to generate configuration using puppet - ie.:

Another point of disparity between how I see others write Puppet manifests and the Best Practice that I''ve adopted at my institution is the use of quoting. In Puppet, you can get away with not quoting values or references if there isn''t a special character or a keyword being used (e.g. package { openssh: ...} or User[agirl]). However, even though that is possible, to make

Hello, I'm running dovecot 2.2 and wanting to get quotas going. I've got the plugins loaded appropriately and am wanting to configure a dictionary backend to talk to my mysql database. I've got a single database called mail which has all the mail-related items in it. One table is for virtual users which postfix uses. It looks like this: CREATE TABLE `virtual_users` ( `id` int(11)

I''m trying to do something like this using puppet 0.24.8. define removeuser() { @ user { $name: ensure => absent } realize User["$name"] } $removelist = ["bob", "bill", "billy"] @ removeuser { $removelist : } It''s failing with "err: Could not retrieve catalog: Failed to realize virtual resources User[bob] on node

Hi, [Note: I''ve been saving up my puppet questions for a free moment so pardon my bombardment of the list] What''s the best way to set up mounts and mountpoints with puppet? I am currently using something like: ---- class software_depot_client { # create NFS mountpoint file { "/mnt/nfs/repository": path => "/mnt/nfs/repository", ensure =>

hi ,all When realizing a resources ,can use this syntax like this ? File <<| tag == $idc | >> I had try it ,but can''t work. and not get error from the puppetmaster. -- Huang Mingyou

Hello, I am trying to get per-user quotas working. My thanks to all who have helped so far. To recap I am running Dovecot 2.1 and Mysql where I've got my virtual users. All virtual users are under the system user vmail with a UID and GID of 5000. Looking over the wiki docs I've added a quota table and got the dict service working, I am not having problems with permissions or the login

I like the Stanford Best Practices guide for puppet. One thing I didn''t see it address was handling of separate environments, for example Dev, Test, Staging, Production. My thoughts on this so far, are: brainstorm #1) Handle environment differences with metadata: node devProductName01 { $env = "dev" include ProductName-webserver } node testProductName01 {