[Puppet Users] Re: environments for several internal customers?
I do that in this way: On puppet.conf on the puppetmaster: --- [puppetmasterd] reports = store,rrdgraph,tagmail,log autosign = true environments = alpha,beta,gamma manifest = /no/file [beta] modulepath = /etc/puppet/data/beta/ manifest = /etc/puppet/manifests/site-beta.pp [alpha] modulepath = /etc/puppet/data/alpha/ manifest = /etc/puppet/manifests/site-alpha.pp [gamma] modulepath = /etc/puppet/data/gamma/ manifest = /etc/puppet/manifests/site-gamma.pp --- /etc/puppet/manifests/site-beta.pp has something like: import project_beta (a module, in where you define your infrastructure, placed in /etc/puppet/data/beta/ ) Permissions on /etc/puppet/data/beta/ are limited to the users/groups that can manage files for the beta environment. On puppet.conf on the client (for example of the beta environment): [main] vardir = /var/lib/puppet logdir = /var/log/puppet rundir = /var/run/puppet ssldir = $vardir/ssl environment = beta [puppetd] classfile = $vardir/classes.txt localconfig = $vardir/localconfig environments = beta You can define also testing / production environments for each department, with something like: On clients: [main] vardir = /var/lib/puppet logdir = /var/log/puppet rundir = /var/run/puppet ssldir = $vardir/ssl environment = betaprod [puppetd] classfile = $vardir/classes.txt localconfig = $vardir/localconfig environments = betatest,betaprod (normal puppetruns use beta-prod, with puppetd -t -- environment=betatest you run on the test environment of beta). puppet.conf on the puppet master becomes something like: [puppetmasterd] reports = store,rrdgraph,tagmail,log autosign = true environments = alphatest,alphaprod,betatest,betaprod ... manifest = /no/file [betatest] modulepath = /etc/puppet/data/beta/test/ manifest = /etc/puppet/manifests/site-beta.pp [betaprod] modulepath = /etc/puppet/data/beta/prod/ manifest = /etc/puppet/manifests/site-beta.pp /etc/puppet/data/beta/test/ and /etc/puppet/data/beta/prod/ are both git clones that pull from something like /etc/puppet/data/beta/ gitrepo My2c Alessandro Franceschi On 7 Set, 10:24, philipp Hanselmann philipp.hanselm...@gmail.com wrote: We are planning to use a puppet server for several internal customers at our school (ETHZ - Swiss Fedral Institute of Technology Zürich). One way could be to choose a separate environment for each customer ... Each customer will get a normal user on the puppet server. With this he can edit his files inside his own environment path ... But how can we ensure that the customers are separated? It should NOT be possible for customer X to choose a environment from customer Y. Is there a way to implement this? Philipp Hanselmann --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet Camp
Thanks for the info, Andrew. I'm waiting for passport reneval procedures and relative timings before confirming my partecipation at the Puppet Camp. I take the occasion for a general broadcast. For the people planning to come to San Francisco some days before the event (to cope with jet-lags or just visit the town) it could be nice to plan some kind of informal meetup, more or less turistical, more or less driven by weird sysadmin jokes ;-) Who is interested for a can reply here or mail me. Best regards, Alessandro Franceschi Lab42 --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Forcing puppetd ask puppemasterd for new changes
--runinterval is an option to be used in daemon mode (place it in puppet.conf) If you trigger puppet via cron, you can decide the interval at cron level. I personally would never place a runinterval value lesser than 30 minutes (3 mins is really extreme, if you need to apply changes immediately use puppetrun, and leave the interval check at 30). ciao On 2 Lug, 10:47, Pavel Shevaev pacha.shev...@gmail.com wrote: Sorry folks, I'm replying to myself but here is what I found out. For some reason running with shorter --runinterval gives me a warning on the second and further update sessions with puppetmasterd: Other end went away; restarting connection and retrying. But puppetmasterd is running for sure Here is a sample verbose session: == pacha...@stage ~ $ sudo puppetd --no-daemonize --server master --verbose --runinterval 30 Password: notice: Starting Puppet client version 0.24.4 info: Retrieving plugins info: Caching catalog at /var/lib/puppet/localconfig.yaml notice: Starting catalog run ... * Some changes are applied here* ... notice: Finished catalog run in 2.15 seconds * Next interval * info: Retrieving plugins info: Configuration is up to date notice: Starting catalog run notice: Finished catalog run in 5.88 seconds info: Retrieving plugins warning: Other end went away; restarting connection and retrying info: Configuration is up to date notice: Starting catalog run notice: Finished catalog run in 1.08 seconds == If I cancel this command witch Ctrl-C and start it again puppetd retrieves the new changes from the master. I definitely don't understand something very obvious related to the proper invocation of the puppetd daemon, please guide into the right direction. -- Best regards, Pavel --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: cronjob every 15 minutes
You can do something like this
cron {
getBroadcast:
command = /server/www-production/www.server.de/cli/
getBroadcastFromFtp.php,
user= root,
weekday = 3,
minute = $hostname ? {
server-vm1 = 15,45,
server-vm2 = 0,30
},
hour= ['8-20'];
}
On 2 Lug, 09:04, Rupert linux...@googlemail.com wrote:
Hello,
im trying to create a class that creates a cronjob that is run ever 15
minutes on 2 Servers.
These jobs should run at 15 and 45 on one server and on 0 and 30 on
the other server.
When i set a variable to '0,30' puppet complains that its not a valid
minute.
Is there a different approach in puppet for this?
Here is my class:
class cronjobs_servers {
case $hostname {
server-vm1: {
$cronminute=15,45
$cronminute2=0
}
server-vm2: {
$cronminute=0,30
$cronminute2=10
}
}
cron {
generate_snapshot:
command = /server/www-production/www.server.de/cli/
generateSnapshot.php,
user = root,
weekday = ['1-5'],
minute = $cronminute2,
hour = 22;
}
cron {
getBroadcast:
command = /server/www-production/www.server.de/cli/
getBroadcastFromFtp.php,
user = root,
weekday = 3,
minute = $cronminute,
hour = ['8-20'];
}
cron {
notifyMissingVideo:
command = /server/www-production/www.server.de/cli/
notifyMissingVideo.php,
user = root,
weekday = 3,
minute = $cronminute,
hour = ['8-20'];
}
cron {
cache_cleanup:
command = nice -n 19 /usr/sbin/tmpwatch -a -d -q 48 /
server/www-production/www.server.de/cache,
user = root,
minute = 2,
hour = 0;
}
}
thx a lot
.r
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: Installing applications using puppet
Once I did this class for mailscanner installation, can be an example.
class mailscanner {
$mailscannerver=MailScanner-4.69.9-2
$mailscannerfile=$mailscannerver.rpm.tar.gz
exec {
mailscanner_prerequisites:
command = $operatingsystem ? {
default = yum install -y wget tar gzip rpm-
build binutils glibc-devel gcc make,
},
onlyif = test ! -f /usr/src/
$mailscannerfile,
}
exec {
mailscanner_download:
command = cd /usr/src ; wget
http://www.mailscanner.info/files/4/rpm/$mailscannerfile;,
onlyif = test ! -f /usr/src/
$mailscannerfile,
require = Exec[mailscanner_prerequisites],
}
exec {
mailscanner_extract:
command = cd /usr/src ; tar -zxvf
$mailscannerfile,
require = Exec[mailscanner_download],
onlyif = test ! -d /usr/src/
$mailscannerver,
}
exec {
mailscanner_install:
command = cd /usr/src/$mailscannerver ; ./
install.sh,
require = [
Exec[mailscanner_extract],
Package[spamassassin],
Package[clamav]
],
unless = rpm -qi mailscanner,
}
service { mailscanner:
name = MailScanner,
ensure = running,
enable = true,
hasrestart = true,
hasstatus = true,
require = Exec[mailscanner_install],
}
}
On Jun 25, 10:42 pm, Neil K sate...@gmail.com wrote:
Hi all,
I am pretty new to Puppet. My puppet master server is a RHEL 5 box and
puppet client is a CentOS 5.3 vm. I have managed to configure puppet
server to successfully install.and upgrade rpm based packages on the
client machine. Is it possible to install noon-rpm based packages
using puppet? Like packages comes as tar.gz such as web based
applications?
If it is possible, please provide any example manifests or any good
documents that I can follow.
Thanks,
Neil
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: EAL4+ general hardening settings with Puppet
Hallo Stephen, Well the two things I missed were: A documentation outlining all the steps being done, and that this is more of a hardening document. It can't bring a system to EAL3/4/x because the hardware and other parts need to be evaluated in toto by some 'authority'. Yes, a more detailed documentation on the steps done with those puppet modules (and the ones not done by the modules but still required) is something I wanted to do, but for time constrains I preferred to write down the operational stuff, leaving for better days complete docs. I don't want to come across as a nitpicker, but the difference is important for people who really need EAL-X. A common problem I have seen is that someone will find something listed as EAL4 and then finding out when the auditors show up they didn't have what they expected. I don't know the best solution to this, but labeling things as hardening guidelines to help meet CAPP is probably better You're right in underlining this but that's what I actually tried to express writing: Consider it a work in progress and by no means a complete solution to achieve a certified EAL4+ system (that involves further steps that range from installation of a systems to operations). o, in the linked http://www.example42.com/wiki/EalHardening page: EAL4+ compliance requires much more than what is configured with the puppet modules provided here: it's a process that starts from the hardware choice, the physical location and accessibility of the servers, their installation, the configuration of the base system (what is covered here) and the used services and also the day by day operations on the system. but maybe you're right if you consider the title of the post, which might be confusing under this point of view. Best regards, Alessandro Franceschi --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: EAL4+ general hardening settings with Puppet
Thanks for the feedback, Larry, - The hardening module I would break out each of these services into separate modules, so it's more generic. The hardening class itself I would consider a 'role' that would then include all of these modules (I have roles exist in the manifest folder and called by site.pp) I agree with you. One of the reasons why I kept it as a module is due to the other hardening subclasses that I didn't know where to place. But I know know if I actually will change that. See below for details. - your logindefs class I would consider part of a shadow module that then has your specific security policy Yes, that makes sense. - your modules are very centos/RH specific any plans on making them apply to other OSes? Only upon request/necessity. I generally work on Centos/RedHat, when I'll face the need to run puppet on other distros/os I'll arrange the modules. They already are genrally done in order to support multi os, but actually all the default values are RH based. - If you are removing packages I would suggest by default installing the package and then creating an ::absent class to remove or a ::disable to stop the service but have the module installed. This also then allows for keeping the package current via that module. I thought about it, but, for packages, I preferred to launch a single removal script (only once) for different reasosn: - It's not mandatory but only suggested to remove those packages. - A plethora of different modules (with actually not much more that the package type) had to be done for most of them - I didn't want to interfere with a possibly large number of modules or possible custom changes by users My point is: the package removal script has to be launched at first puppet run to provide a clean system, then the admins should be free to reinstall the removed packages as a deliberate choice and they should do that via puppet possibly with custom classes, without being sticked to the ones provdived with the hardening class (or role). Note that for services I followed a different approach, managing them with puppet types and probably in this case it's better to divide them in different modules and provide service::disable classes. I'll probably fix this and remove the hardening::service class. I'm not really familiar with EAL4+ CAPP can you tell me more about this? How is something certified EAL4+ CAPP, and can something be certified? Stephen John Smoogen has well replied to this. Consider, as written in various parts, that this set of puppet modules is NOT enough to certify an EAL4+ system. I actually suspect that very few systems in the planet can be considered really EAL4+ RBAC certifiable in ongoing operations (does anyone here use fully labeled networking in his systems?? Do sysadmins ALWAYS follow the EAL4+ operations guidelines? ), but that's another point. Best regards, Alessandro Franceschi --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: EAL4+ general hardening settings with Puppet
Thanks for the feedback, Larry, - The hardening module I would break out each of these services into separate modules, so it's more generic. The hardening class itself I would consider a 'role' that would then include all of these modules (I have roles exist in the manifest folder and called by site.pp) I agree with you. One of the reasons why I kept it as a module is due to the other hardening subclasses that I didn't know where to place. But I know know if I actually will change that. See below for details. - your logindefs class I would consider part of a shadow module that then has your specific security policy Yes, that makes sense. - your modules are very centos/RH specific any plans on making them apply to other OSes? Only upon request/necessity. I generally work on Centos/RedHat, when I'll face the need to run puppet on other distros/os I'll arrange the modules. They already are genrally done in order to support multi os, but actually all the default values are RH based. - If you are removing packages I would suggest by default installing the package and then creating an ::absent class to remove or a ::disable to stop the service but have the module installed. This also then allows for keeping the package current via that module. I thought about it, but, for packages, I preferred to launch a single removal script (only once) for different reasosn: - It's not mandatory but only suggested to remove those packages. - A plethora of different modules (with actually not much more that the package type) had to be done for most of them - I didn't want to interfere with a possibly large number of modules or possible custom changes by users My point is: the package removal script has to be launched at first puppet run to provide a clean system, then the admins should be free to reinstall the removed packages as a deliberate choice and they should do that via puppet possibly with custom classes, without being sticked to the ones provdived with the hardening class (or role). Note that for services I followed a different approach, managing them with puppet types and probably in this case it's better to divide them in different modules and provide service::disable classes. I'll probably fix this and remove the hardening::service class. I'm not really familiar with EAL4+ CAPP can you tell me more about this? How is something certified EAL4+ CAPP, and can something be certified? Stephen John Smoogen has well replied to this. Consider, as written in various parts, that this set of puppet modules is NOT enough to certify an EAL4+ system. I actually suspect that very few systems in the planet can be considered really EAL4+ RBAC certifiable in ongoing operations (does anyone here use fully labeled networking in his systems?? Do sysadmins ALWAYS follow the EAL4+ operations guidelines? ), but that's another point. Best regards, Alessandro Franceschi --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: EAL4+ general hardening settings with Puppet
Thanks for the feedback, Larry, - The hardening module I would break out each of these services into separate modules, so it's more generic. The hardening class itself I would consider a 'role' that would then include all of these modules (I have roles exist in the manifest folder and called by site.pp) I agree with you. One of the reasons why I kept it as a module is due to the other hardening subclasses that I didn't know where to place. But I know know if I actually will change that. See below for details. - your logindefs class I would consider part of a shadow module that then has your specific security policy Yes, that makes sense. - your modules are very centos/RH specific any plans on making them apply to other OSes? Only upon request/necessity. I generally work on Centos/RedHat, when I'll face the need to run puppet on other distros/os I'll arrange the modules. They already are genrally done in order to support multi os, but actually all the default values are RH based. - If you are removing packages I would suggest by default installing the package and then creating an ::absent class to remove or a ::disable to stop the service but have the module installed. This also then allows for keeping the package current via that module. I thought about it, but, for packages, I preferred to launch a single removal script (only once) for different reasosn: - It's not mandatory but only suggested to remove those packages. - A plethora of different modules (with actually not much more that the package type) had to be done for most of them - I didn't want to interfere with a possibly large number of modules or possible custom changes by users My point is: the package removal script has to be launched at first puppet run to provide a clean system, then the admins should be free to reinstall the removed packages as a deliberate choice and they should do that via puppet possibly with custom classes, without being sticked to the ones provdived with the hardening class (or role). Note that for services I followed a different approach, managing them with puppet types and probably in this case it's better to divide them in different modules and provide service::disable classes. I'll probably fix this and remove the hardening::service class. I'm not really familiar with EAL4+ CAPP can you tell me more about this? How is something certified EAL4+ CAPP, and can something be certified? Stephen John Smoogen has well replied to this. Consider, as written in various parts, that this set of puppet modules is NOT enough to certify an EAL4+ system. I actually suspect that very few systems in the planet can be considered really EAL4+ RBAC certifiable in ongoing operations (does anyone here use fully labeled networking in his systems?? Do sysadmins ALWAYS follow the EAL4+ operations guidelines? ), but that's another point. Best regards, Alessandro Franceschi --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet best practices: location specific configuration...
Hi,
How to best manage location-specific configuration
I generally approach this issue with node's inheritance, managing
variables at different levels, according to custom needs..
An example is better than many words:
node basenode {
$puppet_server = 10.42.0.10
$local_network = 10.42.0.0/24
}
node devel inherits basenode {
$local_network = 192.168.0.0/24
$ntp_server = 192.168.0.2
$zone = devel
}
node prod inherits basenode {
$local_network = 10.0.0.0/24
$ntp_server = 10.0.0.14
$puppet_server = 10.0.0.10
$zone = prod
}
node 'delta.lab42.it' inherits devel {
include general::webserver
}
node 'ntp.example42.com' inherits prod {
$ntp_server = 192.43.244.18
include general::ntpserver
}
So,
you can define variables (used then in templates or wherever
necessary) at a top level (basenode) and redefine them at lower levels
(prod, test... generally these are intended as separated networks,
that may have different settings for services ar dsn, ntp and
whatever).
You can also redefine some variables at the node level, for managing
specific cases.
The definition of a $zone variable, can be useful to manage broader
differencies (for example serving totally different files according to
the zone, or including only specific classes
class general {
include sysctl
include puppet
include nrpe
include snmpd
include ntp
include hosts
include cron
include resolver
include syslog
case $zone {
prod: { include hardening }
default: { }
}
}
class general::webserver inherits general {
$role = webserver
include apache
}
Just as a side note, I define $role as the general role of a system
(webserver, loadbalancer, dbserver, mailserver) and use the $role
variable in classes to eventually differentiate configuration on the
role od the system.
So, for each node, you have 2 main characterizations:
- The zone (network) where it stays
- The role (functions) it has
Regards
Al
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
