Currently, since the wso2base::java module is included in the manifests/site.pp, Java parameters such as installation directory, install version are hard coded in the puppet logic in java.pp file. This should be reverted back to the state where java parameters were read from external input such as Hiera.

Additionally, there seems to be remnants of an effort to make the extension of Java installation from Puppet extensible. One such location is the java_class key in Hieradata.

IMO WSO2 Puppet modules rarely need this level of extensibility. Furthermore, it can also introduce complexities that are hard to debug and maintain at deployments. Any details that need to be tweaked according to input needs to be considered and the Puppet logic that drives the Java installation needs to be concrete in terms of implementation.

In brief Java installation should consist of the following flow.

1. Input following parameters from Product module (as Hieradata or Puppet variables)
   1: Installation directory: /mnt/jdk-8u112
   2: Source Distribution: jdk-8u112-linux-x64.tar.gz
   3: JAVA_HOME: /opt/java
   4: User: wso2user
   5: Group: wso2user
   6: Additional configuration information
   7: Install JDK: To install JDK or not

2. These values are read in the Product module's params.pp and are passed in to the wso2base::system module call from the Product module's init.pp.

3. wso2base::system checks if JDK should be installed, and calls the java.pp passing the variables from wso2base::init

4. wso2base::java uses the above passed variables to configure the JDK.

Setting password for wso2 user is not required.

https://github.com/wso2/puppet-base/blob/master/manifests/system.pp#L48

Currently, the JDK is installed without giving a control to the user on whether to opt out of it or not. This should be made configurable in a user-friendly manner where either an easily configurable flag or an intelligent check on existing JAVA_HOME of the specified version can determine whether to actually install Java or not.

As of now /etc/puppet/manifests/site.pp contains the following logic.

node "default" {
  if $::use_hieradata == "true" {
    require wso2base::java
    hiera_include('classes')

  } else {
    class { '::wso2base::java': } -> class { "::${::product_name}": }
  }
}

This should be changed so that, for example, wso2::install_java determines whether to actually install Java or not before invoking product specific modules.

If this is to be changed in a way that the Java module checks for existing installations, it should check for an existing installation of the JDK of,

1. the same version
2. the same JAVA_HOME

and not install only if above those two are satisfied.

Description:
Both puppet-common and puppet-base master branches have improvements and bug fixes
that can be incorporated into one last major release of WSO2 Puppet Modules for Puppet 3.x.
Since we are about to upgrade all our puppet modules to be compatible with the latest Puppet 5.x, before any such major changes been added, it would be good to tag the currently stable code bases into releases for any expected usage by existing customers.

Suggested Labels:
Puppet, Puppet 3.x, WSO2 Puppet Modules

IOT and EI products have different server startup scripts. Therefore we would need to parameterize the following in the wso2service.erb file:

CMD="${CARBON_HOME}/bin/wso2server.sh"

Description:
While verifying wso2is 5.3.0 puppet modules with vagrant came across with below error.
Error: Syntax error at '.'; expected ')' at /tmp/vagrant-puppet/modules-da20236231671f9c79356a4436291d2f/wso2base/manifests/system.pp:80

Syntax issue was reported on following line.
content => template(wso2base/wso2unit.erb)

Suggested Labels:

Suggested Assignees:

Affected Product Version:

OS, DB, other environment details and versions:

Steps to reproduce:
Deploy any wso2 product with vagrant as described in [1].
[1] https://github.com/wso2/puppet-common/tree/master/vagrant

Related Issues:

in axis2.xml is duplicated when using WKA membership scheme. This is because it is included in wka.erb inline template.
https://github.com/wso2/puppet-base/blob/master/templates/clustering/wka.erb

The following error was noticed in params.pp file:

==> default: /usr/lib/ruby/vendor_ruby/puppet/application.rb:364:in run' ==> default: /usr/lib/ruby/vendor_ruby/puppet/util/command_line.rb:137:in run'
==> default: /usr/lib/ruby/vendor_ruby/puppet/util/command_line.rb:91:in execute' ==> default: /usr/bin/puppet:4:in

Description:
template function @line-80 with parameters not having quotes, gives a syntax error during puppet run.

Steps to reproduce:
Perform a vagrant up for any product deployment pattern and see vagrant console for errors.

Description:
Existing puppet modules to support WSO2 products have been written sometime back
to run on top of Puppet 3.x base which was the latest by then.
However, over time Puppet base has evolved quite a lot from its version 3.x family
(3.8 was the last of that family) to version 4.x and by now even to version 5.x (5.3 is the latest).
Due to substantial changes introduced internally to the base with this evolution, currently the compatibility of our existing WSO2 puppet modules remain only with version 3.x family of Puppet base.
Neither on top of Puppet 4.x or 5.x base, we could straightaway run our modules meaning that there exists a timely need for an upgrade depending on the implementation level changes
suggested by Puppet for an upgrade from version 3.x to 5.x.

Phase 1 includes:
[a] - Changes at code-level, required due to non stringified facts
since facter module now supports proper datatypes.
[b] - Directory structure changes - Introduction to a new config and code directory.
[c] - Data directory path change in heira.yaml due to above directory structure changes.
[d] - Change of puppet parser and syntax changes arose due to this parser change.

Suggested Labels:
Puppet, WSO2 Puppet Modules

Description:
In RHEL/CentOS 7.0 it switched to systemd, a system and service manager, that replaces SysV and Upstart used in previous releases of Red Hat Enterprise Linux.

Description:
Existing puppet modules to support WSO2 products have been written sometime back
to run on top of Puppet 3.x base which was the latest by then.
However, over time Puppet base has evolved quite a lot from its version 3.x family
(3.8 was the last of that family) to version 4.x and by now even to version 5.x (5.3 is the latest).
Due to substantial changes introduced internally to the base with this evolution, currently the compatibility of our existing WSO2 puppet modules remain only with version 3.x family of Puppet base.
Neither on top of Puppet 4.x or 5.x base, we could straightaway run our modules meaning that there exists a timely need for an upgrade depending on the implementation level changes
suggested by Puppet for an upgrade from version 3.x to 5.x.

Phase 2 includes:
[a] - Changes to hiera - Require upgrading hiera from heira 3 (currently deprecated
and expected to be removed by puppet 6) to hiera 5.
[b] - Changes to puppet stdlib validate functions - Require replacing them with
validate_legacy functions.
[c] - Changes suggested to params.pp pattern with new in-built support for hiera with Puppet.

Suggested Labels:
Puppet, WSO2 Puppet Modules

wso2service.erb is an templated implementation of
start(), stop() and restart() service calls for a WSO2 server runtime.

All of them do carry inefficient status checks of the server runtime, preceded by sleep calls, that
can result in invalid statuses been returned based on the situation.

For ex: In the start() service call implementation,
we suspend shell execution for 5 seconds and then check for an active PID
to see if a server runtime has been successfully started. This logic is fine if we can always
expect a server start below 5 seconds in time which is not always the case.

Appropriate fix would be to replace sleep calls with an iterative conditional status check.

When using secure vault feature, password-tmp file is not deleted due to lack of permissions (user group and user differs in the password-tmp file)

Currently, the server startup scripts (wso2server.sh) has been hard-coded. Please parameterise this since WSO2 EI has a different startup script (integrator.sh). Better to have this controllable by the products.

"service_refresh_file_list" parameter and "remove_file_list" parameter is not required to be passed to the init's constructor. Furthermore, passing these parameters will break backward compatibility.

Currently WSO2 Puppet Modules use Puppet 3.x. We need to upgrade this to Puppet 4.x:
https://docs.puppet.com/release_notes/

Currently, the README.md has only mentioned support for Debian and Ubuntu operating systems. It would be better to verify WSO2 Puppet modules on other Linux distributions and update this list.

Running puppet on in my client fails; on the puppet server log I see:

2017-09-05 21:25:06,289 ERROR [qtp378607112-60] [puppetserver] Puppet The parameter 'hostname' is declared more than once in the parameter list at /etc/puppetlabs/code/environments/mk01232/modules/wso2am_runtime/manifests/init.pp:87:3

Is this a bug?

I am trying to build wso2 imagaes for apim, when I tried with vagrant up, I am getting this error. I followed the instructions as mentioned. what I could be doing wrong?

==> default: Error: /Stage[main]/Wso2base::Install/Exec[set_ownership_/mnt/wso2am-2.1.0]: Failed to call refresh: Working directory '/mnt/wso2am-2.1.0' does not exist
==> default: Error: /Stage[main]/Wso2base::Install/Exec[set_ownership_/mnt/wso2am-2.1.0]: Working directory '/mnt/wso2am-2.1.0' does not exist```

This issue is with reference to the fixes of
[1] #16
[2] #18

Fixes to above two issues introduce few new properties to wso2base class giving ability to maintain product specific configurations to both Java installation and automatic service startup.

While these changes are vital to maintain product specific settings for both contexts when not using
heiradata, we are unable to accommodate them at the moment due to:
[1] These changes introduce new API change for wso2base class which breaks
the functionality of existing product modules, violating backward compatibility.
[2] An API change should usually involve a major puppet release which is not yet planned.

As a result, here we are suggesting to replace whatever the newly added, global properties to be local
such that the invocation of wso2base class at product modules level never breaks and at the same time, we could still maintain those properties, specific to products when using heira.

When puppet agent is enabled, the service restarts always when the puppet agent polling happens

There needs to be an option to perform instance hardening tasks such as,

1. Cleaning bash history
2. Strengthen Java Cryptography
3. Restricting SSH access

These are required for deployments public PaaS providers where security hardening of the instances should be done at instance provision time.

These configuration steps should be optional and the default should be opted out. Otherwise debugging failed Puppet runs can be tricky.

For a list of hardening recommended by AWS when creating AMIs, please refer to their guide

Description:
Error: Could not start Service[wso2am]: Execution of '/bin/systemctl start wso2am' returned 5: Failed to start wso2am.service: Unit wso2am.service not found.
Error: /Stage[main]/Wso2base::Service/Service[wso2am]/ensure: change from stopped to running failed: Could not start Service[wso2am]: Execution of '/bin/systemctl start wso2am' returned 5: Failed to start wso2am.service: Unit wso2am.service not found.

The service that is created at /etc/init.d/wso2am is not working in latest Ubuntu versions. As an alternative, you can start the server with puppet itself without relying on the service with few code changes.

Suggested Labels:
bug

Suggested Assignees:
N/A

Affected Product Version:
1.0.0

OS, DB, other environment details and versions:
Ubuntu 16

Steps to reproduce:

• Setup master agent setup in Ubuntu 16 by installing puppet version 3.8.X

Related Issues:
N/A