4 avg. rating (80% score) - 1 votes
Searching for a Puppet (software) job? If you are an expert in Puppet (software) then this is for you. Do not worry, we’ve a right answer for your job interview preparation. If you are preparing for Puppet (software) job interview, we will help you in clearing the interview through Wisdomjobs interview questions and answers page. Puppet (software) is an open source software. It follows client-server architecture. It runs on Unix, Linux and Windows. It can be used for testing small applications like a stand alone. Since Puppet is model-driven, not much programming experience is needed. Good knowledge on Puppet (software) is required for this job. Below are the Puppet (software) interview questions and answers which makes you comfortable to face the interviews:
Puppet is a configuration Tool which is use to automate administration tasks. Puppet Agent(Client) sends request to Puppet Master (Server) and Puppet Master Push Configuration on Agent.
Manifests, in Puppet, are the files in which the client configuration is specified.
Whatever the manifests we defined in modules, can call or include into other manifests. Which makes easier management of Manifests.It helps you to push specific manifests on specific Node or Agent.
Sometime you need to write manifests on conditional expression based on agent specific data which is available through Facter. Facter provides information like Kernel version,Dist release, IP Address, CPU info and etc.You can defined your facter also.
By default Puppet Agent request to Puppet Master after a periodic time which known as “runinterval”. Puppet Kick is a utility which allows you to trigger Puppet Agent from Puppet Master.
MCollective is a powerful orchestration framework. Run actions on thousands of servers simultaneously, using existing plugins or writing your own.
Traditionally, managing the configurations of a large group of computers has meant a series of imperative steps; in its rawest state, SSH and a for loop. This general approach grew more sophisticated over time, but it retained the more profound limitations at its root.
Puppet takes a different approach, which is to model everything — the current state of the node, the desired configuration state, the actions taken during configuration enforcement — as data: each node receives a catalog of resources and relationships, compares it to the current system state, and makes changes as needed to bring the system into compliance.
The benefits go far beyond just healing the headaches of configuration drift and unknown system state: modeling systems as data lets Puppet simulate configuration changes, track the history of a system over its lifecycle, and prove that refactored manifest code still produces the same system state. It also drastically lowers the barrier to entry for hacking and extending Puppet: instead of analyzing code and reverse-engineering the effects of each step, a user can just parse data, and sysadmins have been able to add significant value to their Puppet deployments with an afternoon’s worth of perl scripting.
The language used for manifests is ultimately Puppet’s human interface, and XML and YAML, being data formats developed around the processing capabilities of computers, are horrible human interfaces. While some people are comfortable reading and writing them, there’s a reason why we use web browsers instead of just reading the HTML directly. Also, using XML or YAML would limit any assurance that the interface was declarative — one process might treat an XML configuration differently from another.
Yes, Puppet can manage any type of machine, and is used to manage many organizations that have a mix of laptops and desktops.
Yes. As of Puppet 2.7.6 basic types and providers do run on Windows, and the test suite is being run on Windows to ensure future compatibility. More information can be found on the Puppet on Windows page, and bug reports and patches are welcome.
There is no minimum or maximum organization size that can benefit from Puppet, but there are sizes that are more likely to benefit. Organizations with only a handful of servers are unlikely to consider maintaining those servers to be a real problem, while those that have more need to consider carefully how they eliminate manual management tasks.
Yes.All servers are at least somewhat unique, but very few servers are entirely unique; host names and IP addresses (e.g.) will always differ, but nearly every server runs a relatively standard operating system. Servers are also often very similar to other servers within a single organization — all Solaris servers might have similar security settings, or all web servers might have roughly equivalent configurations — even if they’re very different from servers in other organizations. Finally, servers are often needlessly unique, in that they have been built and managed manually with no attempt at retaining appropriate consistency.
Puppet can help both on the side of consistency and uniqueness. Puppet can be used to express the consistency that should exist, even if that consistency spans arbitrary sets of servers based on any type of data like operating system, data centre, or physical location. Puppet can also be used to handle uniqueness, either by allowing special provision of what makes a given host unique or through specifying exceptions to otherwise standard classes.
Puppet Labs (formerly Reductive Labs) is a small, private company focused on re-framing the server automation problem.
The best way to install and upgrade Puppet and Facter is via your operating system’s package management system, using either your vendor’s repository or one of Puppet Labs’ public repositories.
If you have installed Puppet from source, make sure you remove old versions entirely (including all application and library files) before upgrading. Configuration data (usually located in/etc/puppet or /var/lib/puppet, although the location can vary) can be left in place between installs.
Class names can contain lowercase letters, numbers, and underscores, and should begin with a lowercase letter. “::” can be used as a namespace separator.
The same rules should be used when naming defined resource types, modules, and parameters, although modules and parameters cannot use the namespace separator.
Variable names can include alphanumeric characters and underscores, and are case-sensitive.
The puppet language includes a simple documentation syntax, which is currently documented on the Puppet Manifest Documentation wiki page. The puppetdoc command uses this inline documentation to automatically generate RDoc or HTML documents for your manifests and modules.
As described in the Type reference, you need the Shadow Password Library, which is provided by the ruby-shadow package. The ruby-shadow library is available natively for fc6 (and higher), and should build on the corresponding RHEL and CentOS variants.
The variables are all set by Facter. You can get a full listing of the available variables and their values by running facter by itself in a shell.
Not directly. However, Facter reads in custom facts from a special subset of environment variables. Any environment variable with a prefix of FACTER_ will be converted into a fact when Facter runs. For example:
The value of the FACTER_FOO environment variable would now be available in your Puppet manifests as $foo, and would have a value of ‘bar’. Using shell scripting to export an arbitrary subset of environment variables as facts is left as an exercise for the reader.
It is very tempting to enable autosign for all nodes, as it cuts down on the manual steps required to bootstrap a new node (or indeed to move it to a new puppet master).
Typically this would be done with a *.example.com or even * in the autosign.conf file.
This however can be very dangerous as it can enable a node to masquerade as another node, and get the configuration intended for that node. The reason for this is that the node chooses the certificate common name (‘CN’ – usually its fqdn, but this is fully configurable), and the puppet master then uses this CN to look up the node definition to serve. The certificate itself is stored, so two nodes could not connect with the same CN (eg alice.example.com), but this is not the problem.
The problem lies in the fact that the puppet master does not make a 1-1 mapping between a node and the first certificate it saw for it, and hence multiple certificates can map to the same node.
Without autosigning, it would be apparent that bob was trying to get alice’s configuration – as the puppet cert process lists the full fqdn/CN presented. With autosign turned on, bob silently retrieves alice’s configuration.
If you do still choose to have a permanent, or semi-permanent, permissive autosign.conf, please consider doing the following:
Nothing changes for you. Puppet 2.6.x remains licensed as GPLv2. The license change is not retroactive.
As part of this change, we’re also changing the license of the Facter system inventory tool to Apache. This change will take effect with Facter version 1.6.0, and earlier versions of Facter will remain licensed under the GPLv2 license. This change will bring the licensing of Puppet’s two key components into alignment.
Our other major product, MCollective, is already licensed under the Apache 2.0 license.
As part of this license change, Puppet Labs has approached every existing contributor to the project and asked them to sign a Contributor License Agreement or CLA.
Signing this CLA for yourself or your company provides both you and Puppet Labs with additional legal protections, and confirms:
This gives assurance that the origins and ownership of the code cannot be disputed in the event of any legal challenge.
If you haven’t signed a CLA, then we can’t yet accept your code contribution into Puppet or Facter. Signing a CLA is very easy: simply log into your GitHub account and go to our CLA page to sign the agreement.
We’ve worked hard to try find to everyone who has contributed code to Puppet, but if you have questions or concerns about a previous contribution you’ve made to Puppet and you don’t believed you’ve signed a CLA, please sign a CLA or contact us for further information.
The change in license and the requirement for a CLA doesn’t change who owns the code. This is a pure license agreement and NOT a Copyright assignment. If you sign a CLA, you maintain full copyright to your own code and are merely providing a license to Puppet Labs to use your code.
All other code remains the copyright of Puppet Labs.
Puppet requires an MRI Ruby interpreter. Certain versions of Ruby are tested more thoroughly with Puppet than others, and some versions are not tested at all. Run ruby –version to check the version of Ruby on your system.
Starting with Puppet 4, puppet-agent packages do not rely on the OS’s Ruby version, as it bundles its own Ruby environment. You can install puppet-agent alongside any version of Ruby or on systems without Ruby installed. Likewise Puppet Enterprise does not rely on the OS’s Ruby version, as it bundles its own Ruby environment. You can install PE alongside any version of Ruby or on systems without Ruby installed. The Windows installers provided by Puppet Labs don’t rely on the OS’s Ruby version, and can be installed alongside any version of Ruby or on systems without Ruby installed.
A node is any physical or virtual system that is managed by Puppet. This could be a physical server in your data center, a virtual server in the cloud or even a desktop machine.
Changes and requests are ticketed through Jira and we manage requests through an internal process. Then, we use Git and Puppet’s Code Manager app to manage Puppet code in accordance with best practices. Additionally, we run all of our Puppet changes through our continuous integration pipeline in Jenkins using the beaker testing framework.”
Puppet (software) Related Tutorials
|ITIL Configuration Management Tutorial||Change Management Tutorial|
|Perl Scripting Tutorial||Python Tutorial|
|Cloud Computing Tutorial||Hadoop Tutorial|
Puppet (software) Related Interview Questions
|ITIL Configuration Management Interview Questions||Change Management Interview Questions|
|Perl Scripting Interview Questions||Python Interview Questions|
|Cloud Computing Interview Questions||Hadoop Interview Questions|
|Amazon Web Services (AWS) Interview Questions||Hadoop Administration Interview Questions|
|Nagios Admin Interview Questions||Advanced Linux Interview Questions|
|VMware Interview Questions||Configuration Manager Interview Questions|
|Aws Devops Interview Questions|
Puppet (software) Related Practice Tests
|ITIL Configuration Management Practice Tests||Change Management Practice Tests|
|Perl Scripting Practice Tests||Python Practice Tests|
|Cloud Computing Practice Tests||Hadoop Practice Tests|
|Amazon Web Services (AWS) Practice Tests||Hadoop Administration Practice Tests|
About Embedded Linux
Configuring The Software Environment
Target Emulation And Virtual Machines
Starting Your Project
Getting Linux For Your Board
Creating A Linux Distribution From Scratch
Booting The Board
Configuring The Application Development Environment
Kernel Configuration And Development
Using Open Source Software Projects
Handling Field Updates
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.