How to configure Sonatype Nexus repository with Maven?

configure-sonatype-nexus-repository-with-maven

How to configure Sonatype Nexus repository with Maven?

 

Automatic dependencies is one of the powerful feature of Apache maven and its one of the reason Maven is very popular in developer community. Maven resolve the dependent library from local repository which is again connected with central repository or remote repository. thus we can say that Maven has 3 kinds of repository concept.

 

1. Local repostory e.g $USER_HOME/.m2
2. Central repostory e.g http://repo.maven.apache.org/maven2/
3. Private repostory e.g Sonatype Nexus, Artifactory, Archiva etc.
The diagram shown below represent how maven resolve the dependendency.

 
High Level Interaction between Local Repository, Central Repository and Remote Repository.


Dependency Management using Local Repository, Central Repository and Remote Repository.

This is How maven interact with Repository!


This is a diagram which shows the define flow in which maven try to resolve the dependency.

 

Now, We have understood that Central rrepository is in built but next questions is, How to inform the maven about the location of remote repository? In order to configure maven with remote repostory, in our case SonaType Nexus, we need to configuring host machine setting.xml and projects pom.xml to use your Nexus repos.

 

Put this in your ~/.m2/settings.xml file. This will configure the credentials to publish to your hosted repos, and will tell your mvn to use your repo as a mirror of central:

And now configure your projects.

If you want only to download dependencies from Nexus, put this in the pom.xml:

and

Add the following at the end of setting.xml

<activeProfiles>

    <!–make the profile active all the time –>

    <activeProfile>nexus</activeProfile>

  </activeProfiles>

 

Reference

https://maven.apache.org/guides/mini/guide-mirror-settings.html

Tagged : / / / / /

How can we do the security analysis using SonarQube?

security-analysis-using-sonarqube

How can we do the Security analysis using SonarQube?

For Security analysis purposes, a source code security analyzer
– examines source code to
– detect and report weaknesses that can lead to security vulnerabilities.

 

They are one of the last lines of defense to eliminate software vulnerabilities during development or after deployment. A Source Code Security Analysis Tool Functional Specification is available.

 

The SonarQube Quality Model has three different types of rules: Reliability (bug), Vulnerability (security), and Maintainability (code smell) rules. But divided another way, there are only two types: security rules, and all the rest.

 

To be clear, the standard for most rules implemented in SonarQube language plugins is very strict: no false positives. For normal rules, you should be able to be confident that whatever is reported to you as an issue really is an issue.

 

The vast majority of security-related rules originate from established standards: CWE, SANS Top 25, and OWASP Top 10. To find rules that relate to any of these standards, you can search rules either by tag or by text.

 

CWE – Common Weakness Enumeration (CWE™) is a formal list or dictionary of common software weaknesses that can occur in software’s architecture, design, code or implementation that can lead to exploitable security vulnerabilities.

 

SANS Top 25 – The SANS Top 25 list is a collection of the 25-most dangerous errors listed in the CWE, as compiled by the SANS organization.

 

OWASP Top 10 – OWASP stands for Open Web Application Security Project.The OWASP Top 10 is a list of broad categories of weaknesses, each of which can map to many individual rules.

 

XANITIZER – XANITIZER provides an integration with the code quality management platform SonarQube. It transfers all security relevant XANITIZER findings to SonarQube. It is possible to display this data in the SonarQube dashboard and the corresponding drilldown pages and time machines.

 

Reference
Tagged : / / / /

SonarQube Upgrade, Backup and Restore Process | SonarQube Tutorial

sonarqube-upgrade-backup-and-restore-process

 

SonarQube Upgrade, Backup and Restore Process

 

Today I will share the steps to upgrade from the SonarQube version 5.X to SonarQube version 6.X. We have upgrade guide which can be found http://docs.sonarqube.org/display/SONAR/Upgrading but its not complete guide thus I am sharing the steps as follows which can be followed for the production server as well.  As practice shared on the oficial guide that before upgrading to the next major release, you must upgrade to know LTS e.g
Example 1 : 4.2 -> 6.1, migration path is 4.2 -> 4.5.7 LTS -> 5.6 LTS -> 6.1
Example 2 : 5.1 -> 5.6, migration path is 5.1 -> 5.6

 

Upgrading across multiple versions is handled automatically. However, if in your migration path you have an LTS version, you must first migrate to this LTS and then migrate to your target version.

 

Remember that SonarQube upgrade procedure does not have a rollback procedure, so it is mandatory that you take a full backup of the system before performing the upgrade.

 

Process 1: Steps to Take a Full Backup of SonarQube Server?

Step 1 – Stop the production server
Windows
%SONARQUBE_HOME%/bin/windows-x86-32/StopNTService.bat
Linux
$SONAR_HOME/bin/linux-x86-64/sonar.sh stop
Step 2 – Backup the production database e.g mysql db
> mysqldump –opt -Q -h localhost -u username–password=’password’ databasename | gzip -9 > databasename.gz
Also, there is one tool which has been available to take the backup of database.
Step 3 – Backup the $SONAR_HOME directory
> zip -r Sonar_home.zip $SONAR_HOME
Step 4 – List of plugins installed
Be mindful that $SONAR_HOME/extensions/plugins directory where you can get the list of plugins installed.
Step 5 – List of custom coding rules installed
Be mindful that $SONAR_HOME/extensions/rules directory where you can get the list of custom coding rules.
Step 6 – List of configurations used
Be mindful that $SONAR_HOME/config directory where you can get sonar.properties and wrapper.conf file which has all the current configurations and setup.
Step 7 – Re-start the production server
Windows
%SONARQUBE_HOME%/bin/windows-x86-32/StartSonar.bat
Linux
$SONAR_HOME/bin/linux-x86-64/sonar.sh start
Step 8: Keep the Sonar_home.zip and databasename.gz to the safe location.

 

Process 2: SonarQube server Upgrade process.

Following are the steps to be followed to upgrade the SonarQube server.
Step 1: Stop your old SonarQube Server.
Step 2: Install/Configure a most latest version of SonarQube 
Install/Configure a most latest version of SonarQube Server in another location. The instructions is shared here (https://docs.sonarqube.org/display/SONAR/Installing+the+Server)
Step 3: Install the your required plugins/extensions compatible with your version of SonarQube. The Instructions is shared here.(https://docs.sonarqube.org/display/SONAR/Installing+a+Plugin)
Step 4: Update the contents of sonar.properties and wrapper.conf files (in NEW_SONARQUBE_HOME/conf) with the settings of the related files in the OLD_SONARQUBE_HOME/conf directory (web server URL, database, ldap settings, etc.). Do not copy-paste the old files.
If you are using the Oracle DB, copy its JDBC driver into NEW_SONARQUBE_HOME/extensions/jdbc-driver/oracle
Step 5: Start your new SonarQube Server
Windows
%SONARQUBE_HOME%/bin/windows-x86-32/StartSonar.bat
Linux
$SONAR_HOME/bin/linux-x86-64/sonar.sh start
Step 7: Verify the SonarQube Upgrade.

 

Note – SonarQube as a Linux or Windows Service
If you use external configuration, such as a script or Windows Service to control your server, you’ll need to update it to point to NEW_SONARQUBE_HOME.
In case you used the InstallNTService.bat to install SonarQube as a Windows Service, run the OLD_SONARQUBE_HOME/bin/…/UninstallNTService.bat before running the InstallNTService.bat of the NEW_SONARQUBE_HOME.
If you install SonarQube with Sql Server, it is better to chose Latin1_General_CS_AS as collation to avoid problems.

 

Some Well known Troubleshooting after upgrades.
Issues – Sonarqube upgrade 5.6 to 6.1, test coverage measue is missing
Solution – You might be missing the sonar.java.binaries. Sonar-5.6 did not need those.
Issues – Some unknown issues
Solution – Whenever you have problem with SonarQube do not forget to read the log, because only in the log you can understand the real cause of errors.

 

Reference
Tagged : / / / / / / /

SonarQube Frequently asked questions (FAQ) | SonarQube FAQs

sonarqube-faqs

 

SonarQube Frequently asked questions (FAQ)

Is SonarQube Replacement for Checkstyle, PMD, FindBugs?
————————————————————–

Answers – YES and NO

Why Yes?
Sonar will run CheckStyle, FindBugs and PMD, as well as a few other “plugins” such as Cobertura (code coverage) by default for Java projects. The main added value, however, is that it stores the history in a database. You can then see the trend. Are you improving the code base or are you doing the opposite? Only a tool with memory can tell you that.
Why No?
SonarQube is currently on the way to deprecate PMD, Checkstyle and Findbugs and use their own technology to analyze Java code (called SonarJava). They do it, because they don’t want to spend their time fixing, upgrading (or waiting on it) those libraries (e.g. for Java 8), which for example uses outdated libraries. Well at least since SonarQube 6.3+ it seems to be that Findbugs is (at the moment) no longer supported as a plugin.

 

What is the SonarQube Plugins available which can be integrated with Eclipse, IntelliJ IDEA, Visual Studio, Visual Studio Code, and Atom?
————————————————————–
Answer –
SonarLint is an extension to your favorite IDE that provides on-the-fly feedback to developers on new bugs and quality issues injected into their code.
Reference

 

Where i can get the Support related to SonarQube?
————————————————————–
Google Grops
Facebook Groups
Linkedin Groups
Public Forum

 

Top 10 Lessons Learned from 2 Years Work with Codehaus Sonar
————————————————————–

 

Configure Sonar to exclude files from Maven pom.xml
————————————————————–

 

Does Sonar support multiple language in same project ex. sonar.language=java,grvy?
————————————————————–
Starting with SonarQube 4.2, multi-language projects are supported.
This automatically happens when sonar.language is not set.

 

How to exclude the directory in SonarQube?
————————————————————–
try something like this:
sonar.exclusions=src/java/test/**

sonar.exclusions=system/**, test/**, application/third_party/**, application/logs/**

How to Increase SonarQube Heap Size?
————————————————————–
Whenever you get a issues like “SonarQube analysis failed java.lang.OutOfMemoryError: Java heap space”, you may following options to follow.
Option 1 – Reduce the analyze scope by either reducing the project size(split your project in smaller sub projects/modules) or reducing the set of rules that are analyzed.
Option 2 – Increase the memory size that can be consumed by the JVM.  This can be done by adding the following Environment Variable:
SONAR_RUNNER_OPTS=”-Xmx3062m -XX:MaxPermSize=512m -XX:ReservedCodeCacheSize=128m”
e.g Linux
> export SONAR_SCANNER_OPTS=”-Xmx3062m -XX:MaxPermSize=512m -XX:ReservedCodeCacheSize=128m”
e.g Windows
> set SONAR_SCANNER_OPTS=”-Xmx3062m -XX:MaxPermSize=512m -XX:ReservedCodeCacheSize=128m”

 

Reference
Tagged : / / / / /

What are the alternatives of SonarQube for Code Quality Management?

sonarqube-alternatives

 

Alternate of SonarQube for Code Quality Management tools?

There is not a popular known alternate of SonarQube and Reasonable is definitely dominating the Software Quality management domain in terms of open source category. But you may try following tools depends on the use and project requirements.

 

JSHint (Java Script Only)
JSHint is a community-driven tool that detects errors and potential problems in JavaScript code. Since JSHint is so flexible, you can easily adjust it in the environment you expect your code to execute. JSHint is open source and will always stay this way. It is a program that flags suspicious usage in programs written in JavaScript. The core project consists of a library itself as well as a CLI program distributed as a Node module. This tool used in software development for checking if JavaScript source code complies with coding rules
More Info can be found here – http://jshint.com/about/

 

HPE Fortify
HPE Fortify Software Security Center enables any organization of any size to automate any or all aspects of a successful SSA program. Part of the family of HPE Enterprise Security Products, HPE Fortify Software Security Center is comprised of industry-leading products, solutions, and features that address the complete spectrum of your application security needs.

 

HPE Fortify Software Security Center can help you:
– Address immediate security issues in software you’ve already deployed.
– Reduce systemic risk in software you’re developing or acquiring from vendors.
– Meet compliance goals for internal and external security mandates.
– HPE WebInspect Real-Time
– Interactive vulnerability review and management
– Advanced web services security testing
– HPE WebInspect Trend Reporting
– Refined and simple usability
– Actionable remediation and compliance reports

 

Coverity
Synopsys Static Analysis (Coverity®) is an accurate and comprehensive static analysis and Static Application Security Testing (SAST) platform that finds critical defects and security weaknesses in code as it’s written before they become vulnerabilities, crashes, or maintenance headaches. It is Static Code Analysis tool. Find critical defects and security weaknesses in code as it’s written before they become vulnerabilities, crashes, or maintenance headaches.

 

More Info can be found at
Tagged : / / / / / / /

What is SonarQube and What is not?

what-is-sonarqube

 

What is SonarQube?

It’s a code quality management platform that allows developer teams to manage, track and eventually improve the quality of the source code.  It’s a web based application that keeps historical data of a variety of metrics and gives trends of leading and lagging indicators for all seven deadly sins of developers.
Sonar is an open source platform used by development teams to manage source code quality. Sonar has been developed with a main objective in mind: make code quality management accessible to everyone with minimal effort.

As such, Sonar provides code analyzers, reporting tools, defects hunting modules and TimeMachine as core functionality. But it also embarks a plugin mechanism enabling the community to extend the functionality (more than 35 plugins available), making Sonar the one-stop-shop for source code quality by addressing not only developers but also managers needs.


Main Feature of SonarQube

Continuous Inspection
SonarQube provides the capability to not only show health of an application but also to highlight issues newly introduced. With a Quality Gate in place, you can fix the leak and therefore improve code quality mechanically.
Detect Tricky Issues
Our code analyzers are equipped powerful path sensitive dataflow engines to detect tricky issues such as null-pointers dereferences, logic errors, resource leaks
Centralize Quality
One place to provide a shared vision of code quality for developers, tech leads, managers and executives in charge of a few to a few thousands projects and also to act as a toll gate for application promotion or release.
DevOps Integration
SonarQube integrates with the entire DevOps toolchain including build systems, CI engines, promotion pipelines… using webhooks and its comprehensive RestAPI.
20+ Programming Languages
With SonarQube comes a code analyzer for each major programming language. Each analyzer provides numerous rules to spot general and language-specific quality issues.

 

What SonarQube is Not?

SonarQube is NOT a build tool. Period. There are several tools out there like Maven, Ant, Gradle etc. that do a perfect job on that field. SonarQube expects that before you analyze a project it has been already compiled and built by your favorite build tool.
SonarQube is NOT (only) a static code analyzer : It’s not a replacement for FindBugs or CPPCheck or any other similar tool. On the contrary, not only it offers its own static code analysis mechanism that detects coding rules violations but at the same time it’s integrated with external tools like the ones I mentioned. The result is that you can get, homogenized, in a single report all issues detected by a variety of static and dynamic analysis tools.
SonarQube is NOT a code coverage tool : Clearly NOT. Again it’s integrated with the most popular test coverage tools like JaCoCo, Cobertura, PHPUnit etc. but it doesn’t compute code coverage itself. It reads pre-generated unit test report files and displays them in an extremely convenient dasboard.
SonarQube is NOT a code formatter. It’s not allowed to modify your code in any way. However you can get formatting suggestions by enabling the CheckStyle, CPPCheck, ScalaStyle rules you want to follow.
SonarQube is NOT a continuous integration system to run your nightly builds : You can integrate it with the most popular CI Engines to apply Continuous Inspection but it’s not their replacement.

SonarQube is NOT just another manual code review tool. Indeed SonarQube offers a very powerful mechanism that facilitates code reviews but this is not a standalone features. It’s tight to the issues detection mechanism so every code review can be easily associated to the exact part of the problematic code and the developer that caused it.

Reference
https://www.sonarqube.org/
http://softwaregarden.io/sonarqube/

 

Tagged : / / / / / / /

What is SonarJava? Is it replacement for Checkstyle, PMD, FindBugs?

know-about-sonarjava

SonarJava has a great coverage of well-established quality standards. The SonarJava capability is available in Eclipse and IntelliJ for developers (SonarLint) as well as throughout the development chain for automated code review with on-premise SonarQube or on-line SonarCloud.

SonarJava is a code analyzer for Java projects. Information about the SonarJava features is available below;
Why SonarJava?
SonarQube is currently on the way to deprecate PMD, Checkstyle and Findbugs and use their own technology to analyze Java code (called SonarJava). They do it, because they don’t want to spend their time fixing, upgrading (or waiting on it) those libraries (e.g. for Java 8), which for example uses outdated libraries. Well at least since SonarQube 6.3+ it seems to be that Findbugs is (at the moment) no longer supported as a plugin.

Features
409+ rules (including 103+ bug detection, 273 Code Smells, 33 Vulerabilities)
Metrics (complexity, number of lines etc.)
Import of test coverage reports
Custom rules
SonarJava is being used in the following…
SonarQube
SonarCloud
SonarLint for Eclipse
SonarLint for Intellij IDEA
Supported versions, frameworks and special analyses…
Java language versions through 8
Frameworks Struts, Spring, Hibernate
Native integration with Maven, Gradle, and Ant
Metrics
Code Coverage by Tests: SonarJava supports the import of JaCoCo and Cobertura test coverage reports.
Custom Rules
SonarJava supports custom rules written in Java.
Reference
Tagged : / / / / / / /

Logging in Chef Explained

logging-in-chef-explained

Chef Server
All logs generated by the Chef server can be found in /var/log/opscode. Each service enabled on the system also has a sub-directory in which service-specific logs are located, typically found in /var/log/opscode/service_name.

The Chef server has built-in support for easily tailing the logs that are generated. To view all the logs being generated on the Chef server, enter the following command:
> chef-server-ctl tail

To view logs for a specific service:
> chef-server-ctl tail SERVICENAME
where SERVICENAME should be replaced with name of the service for which log files will be viewed. SERVICENAME represents the name of any service that is listed after running the “> chef-server-ctl service-list” subcommand.

Another way to view log files is to use the system utility tail:
> tail -50f /var/log/chef-server/opscode-chef/current
> tail -50f /var/log/opscode/opscode-chef/current

Supervisor Logs
Supervisor logs are created and managed directly by the service supervisor, and are automatically rotated when a the current log file reaches 1,000,000 bytes. 10 log files are kept. The latest supervisor log is always located in /var/log/chef-server/service_name/current and rotated logs have a filename starting with @ followed by a precise tai64n timestamp based on when the file was rotated.

Supervisor logs are available for the following services:

  1. bifrost
  2. bookshelf
  3. nginx
  4. opscode-erchef
  5. opscode-expander
  6. opscode-expander-reindexer
  7. opscode-solr4
  8. postgresql
  9. rabbitmq
  10. redis

nginx

The nginx service creates both supervisor and administrator logs. The administrator logs contain both access and error logs for each virtual host utilized by the Chef server. Each of the following logs require external log rotation.

Logs Description
/var/log/opscode/nginx/access.log The Web UI and API HTTP access logs.
/var/log/opscode/nginx/error.log The Web UI and API HTTP error logs.
/var/log/opscode/nginx/internal-account.access.log The opscode-account internal load-balancer access logs.
/var/log/opscode/nginx/internal-account.error.log The opscode-account internal load-balancer error logs.
/var/log/opscode/nginx/internal-authz.access.log The opscode-authz internal load-balancer access logs.
/var/log/opscode/nginx/internal-authz.error.log The opscode-authz internal load-balancer error logs.
/var/log/opscode/nginx/internal-chef.access.log The opscode-chef and opscode-erchef internal load-balancer access logs.
/var/log/opscode/nginx/internal-chef.error.log The opscode-chef and opscode-erchef internal load-balancer error logs.
/var/log/opscode/nginx/nagios.access.log The nagios access logs.
/var/log/opscode/nginx/nagios.error.log The nagios error logs.
/var/log/opscode/nginx/rewrite-port-80.log The rewrite logs for traffic that uses HTTP instead of HTTPS.

To follow the logs for the service:

 $ chef-server-ctl tail nginx

Chef Client

Client.rb3 file might help you. Default value of log_location is STDOUT. You can give /path/to/log_location in place of this. You can locate this client.rb file in C:\chef\client.rb or /etc/chef/client.rb directories.

Use the verbose logging that is built into the chef-client:
-l LEVEL, –log_level LEVEL
The level of logging to be stored in a log file.
-L LOGLOCATION, –logfile c
The location of the log file. This is recommended when starting any executable as a daemon. Default value: STDOUT.

Knife
Use the verbose logging that is built into knife:
-V, –verbose
Set for more verbose outputs. Use -VV for maximum verbosity.

chef-solo
-l LEVEL, –log_level LEVEL
The level of logging to be stored in a log file.

The Chef file and folder locations are different on Linux and Windows machines. This article explains the purpose of each file and the location.

Summary

Linux Windows
Cookbook location /var/chef/cache/cookbooks  C:\chef\cache\cookbooks
Chef Client run log /var/log/chef.log First run only
C:\chef\chef-client.log
Subsequent Chef client runs
C:\chef\log\client.log
Error log /var/chef/cache/chef-stacktrace.out C:\chef\cache\chef-stacktrace.out
Ohai output /var/chef/cache/failed-run-data.json C:\chef\cache\failed-run-data.json
Recommended location for custom log files /tmp/cheflog.log C:\Logs\Chef\cheflog.log
Chef Client configuration /etc/chef/client.rb C:\chef\client.rb

 

When you test your cookbook in Test Kitchen

The .kitchen.yml file contains the username to execute the Chef cookbook. It is specified under platforms:, transport:, username:

Use that value in place of USER-NAME-FROM-KITCHEN-YML below.

Linux Windows
Cookbook location /tmp/kitchen/cookbooks
/tmp/kitchen/cache/cookbooks
 C:\Users\USER-NAME-FROM-KITCHEN-YML\AppData\Local\Temp\kitchen\cookbooks
Error log /tmp/kitchen/cache/chef-stacktrace.out C:\Users\USER-NAME-FROM-KITCHEN-YML\AppData\Local\Temp\kitchen\cache\chef-stacktrace.out
Ohai output /tmp/kitchen/cache/failed-run-data.json C:\Users\USER-NAME-FROM-KITCHEN-YML\AppData\Local\Temp\kitchen\cache\failed-run-data.json
Data bags /tmp/kitchen/data_bags C:\Users\USER-NAME-FROM-KITCHEN-YML\AppData\Local\Temp\kitchen\data_bags

 
Cookbook location

When the Chef recipes are executed, all cookbooks are stored on the node. You can examine the code to make sure your latest changes are reflected on the machine.

The log of the Chef client run

The output of the Chef cookbook execution is in the chef.log or chef-client.log file

On Windows

The log of the first Chef Client run and subsequent runs are stored in different log files. After the initial Chef Client run, the rest of the log entries are collected in the second file.

Stacktrace

Chef saves information on the hard drive when scripts are executed. If there is a failure, the stack trace of the last error is saved in the chef-stacktrace.out file.

Ohai output

All the information that Ohai collects on the instance, is saved in the failed-run-data.jsonfile, even if there is no error. It is a great resource to get the server specific values.

Reference

https://docs.chef.io/server_logs.html
https://docs.chef.io/debug.html

Tagged : / / / / /

Chef notifies and subscribes explained with examples

chef-notifies-and-subscribes-explained-with-examples

 

Chef notifies and subscribes explained with examples

A notification is a property on a resource that listens to other resources in the resource collection and then takes actions based on the notification type (notifies or subscribes).

 

Timers

A timer specifies the point during the chef-client run at which a notification is run. The following timers are available:
:before
Specifies that the action on a notified resource should be run before processing the resource block in which the notification is located.
:delayed
Default. Specifies that a notification should be queued up, and then executed at the very end of the chef-client run.
:immediate, :immediately
Specifies that a notification should be run immediately, per resource notified.

 

Notifies

A resource may notify another resource to take action when its state changes. Specify a ‘resource[name]’, the :action that resource should take, and then the :timer for that action. A resource may notify more than one resource; use a notifies statement for each resource to be notified.
The syntax for notifies is:
notifies :action, ‘resource[name]’, :timer

 

Example
The following examples show how to use the notifies notification in a recipe.

 

Delay notifications
template ‘/etc/nagios3/configures-nagios.conf’ do
  # other parameters
  notifies :run, ‘execute[test-nagios-config]’, :delayed
end

 

Notify immediately
By default, notifications are :delayed, that is they are queued up as they are triggered, and then executed at the very end of a chef-client run. To run an action immediately, use :immediately:
template ‘/etc/nagios3/configures-nagios.conf’ do
  # other parameters
  notifies :run, ‘execute[test-nagios-config]’, :immediately
end
and then the chef-client would immediately run the following:
execute ‘test-nagios-config’ do
  command ‘nagios3 –verify-config’
  action :nothing
end

 

Subscribes

A resource may listen to another resource, and then take action if the state of the resource being listened to changes. Specify a ‘resource[name]’, the :action to be taken, and then the :timer for that action.
Note that subscribes does not apply the specified action to the resource that it listens to – for example:
file ‘/etc/nginx/ssl/example.crt’ do
   mode ‘0600’
   owner ‘root’
end
service ‘nginx’ do
   subscribes :reload, ‘file[/etc/nginx/ssl/example.crt]’, :immediately
end
In this case the subscribes property reloads the nginx service whenever its certificate file, located under /etc/nginx/ssl/example.crt, is updated. subscribes does not make any changes to the certificate file itself, it merely listens for a change to the file, and executes the :reload action for its resource (in this example nginx) when a change is detected.
The syntax for subscribes is:
subscribes :action, ‘resource[name]’, :timer

 

Examples
The following examples show how to use the subscribes notification in a recipe.
Prevent restart and reconfigure if configuration is broken
Use the :nothing action (common to all resources) to prevent the test from starting automatically, and then use the subscribes notification to run a configuration test when a change to the template is detected:
execute ‘test-nagios-config’ do
  command ‘nagios3 –verify-config’
  action :nothing
  subscribes :run, ‘template[/etc/nagios3/configures-nagios.conf]’, :immediately
end

 

Reference
Example
Tagged : / / / / / / / /

Chef Internal – How Chef maintain the state of each resources internally?

chef-internal

Chef Client

A chef-client is an agent that runs locally on every node that is under management by Chef. The chef-client executable can be run as a daemon. When a chef-client is run, it will perform all of the steps that are required to bring the node into the expected state, including:

  • Registering and authenticating the node with the Chef server
  • Building the node object
  • Synchronizing cookbooks
  • Compiling the resource collection by loading each of the required cookbooks, including recipes, attributes, and all other dependencies
  • Taking the appropriate and required actions to configure the node
  • Looking for exceptions and notifications, handling each as required

RSA public key-pairs are used to authenticate the chef-client with the Chef server every time a chef-client needs access to data that is stored on the Chef server. This prevents any node from accessing data that it shouldn’t and it ensures that only nodes that are properly registered with the Chef server can be managed.

Ohai

 

Ohai is a tool that is used to collect system configuration data, which is provided to the chef-client for use within cookbooks. Ohai is run by the chef-client at the beginning of every Chef run to determine system state. Ohai includes many built-in plugins to detect common configuration details as well as a plugin model for writing custom plugins.

The types of attributes Ohai collects include but are not limited to:

  • Operating System
  • Network
  • Memory
  • Disk
  • CPU
  • Kernel
  • Host names
  • Fully qualified domain names
  • Virtualization
  • Cloud provider metadata

Attributes that are collected by Ohai are automatic level attributes, in that these attributes are used by the chef-client to ensure that these attributes remain unchanged after the chef-client is done configuring the node.

Ohai collects data for many platforms, including AIX, Darwin, Linux, FreeBSD, OpenBSD, NetBSD, Solaris, and any Microsoft Windows operating systems.

Reference
https://docs.chef.io/chef_client.html

Tagged : / / / / / /