voxpupuli / puppet-jira Goto Github PK

Hi there I've just started to use your module and I was wondering if it's possible for you to register it on forge.puppetlabs.com so it's easier to include it in librarian-puppet and for others to find it?

We should use service_provider to ship init files.

[root@puppetdb2 ~]# facter -p service_provider operatingsystem operatingsystemmajrelease
operatingsystem => CentOS
operatingsystemmajrelease => 6
service_provider => redhat

[root@rundeck ~]# facter -p service_provider operatingsystem operatingsystemmajrelease
operatingsystem => CentOS
operatingsystemmajrelease => 7
service_provider => systemd

I tried defining product => 'servicedesk' but it looks like the download fails.

I can see a file "atlassian-servicedesk-3.1.2.tar.gz_..." under /tmp. The correct filename seems to be "atlassian-servicedesk-3.1.2-jira-7.1.2.tar.gz".

Best regards,

Denny

Add option to install Oracle Java Connector

https://confluence.atlassian.com/display/JIRA/Connecting+JIRA+to+Oracle
https://confluence.atlassian.com/display/JIRA/Supported+Platforms
http://www.oracle.com/technetwork/database/enterprise-edition/jdbc-112010-090769.html

I tried to used this module do install actual JIRA version 7.1.4 but even wget did not download installation files. Is this module obsolete?

After commit e2f929f, I'm not able to set custom configuration in jira-config.properties anymore, as the file is now controlled by puppet-jira.

There are no options for providing own properties, and the only reason for managing this file was to disable WebSudo.

A number of solution would be acceptable to most users:

• Don't manage the file unless the default setting is overridden
• Manage the file with Augeas
• Allow users to provide a map of key/value pairs to be appended to the file

I'm trying to use puppet-jira from Vagrant. In my puppet manifest I have:

class { 'jira': javahome    => '/opt/java/jdk1.7.0_21/' }

and I get complaints about missing parameters for Deploy::Untar, such as:

Must pass group to Deploy::Untar[/var/tmp/deploy/atlassian-jira-6.0.tar.gz] at /tmp/vagrant-puppet-2/modules-0/deploy/manifests/untar.pp:45 on node precise32.atlassian.pl

where group is sometimes replaced by other parameters (e.g. user, command_options).

I've cloned both puppet-jira and puppet-deploy modules from git master.

It looks like jira module is not providing required parameters to deploy calls. Is this a known issue?

When using SSL and proxy together, Tomcat fails on startup with

SEVERE: Parse Fatal Error at line 75 column 35: Attribute "scheme" was already specified for element "Connector".

Example declaration:

  class { '::jira':
    javahome           => $profile::java::java_home,
    tomcatNativeSsl    => true,
    proxy              => {
      scheme    => 'https',
      proxyPort => '443',
      proxyName => 'jira.example.org',
    }
  }

The server.xml.erb template should not add scheme twice in this case.

Can you please help me run it?

OS: Centos 6.5
DB:MySQL

This is my init.pp file:
class {'jira':
javahome => '/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.45.x86_64/',
downloadURL => 'http://downloads.atlassian.com/software/jira/downloads/',
}

And this is th result:

[root@localhost manifests]# puppet apply init.pp
Warning: Config file /etc/puppet/hiera.yaml not found, using Hiera defaults
Warning: Scope(Deploy::File[atlassian-jira-6.0.tar.gz]): Could not look up qualified variable 'deploy::tempdir'; class deploy has not been evaluated
Warning: Scope(Deploy::File[atlassian-jira-6.0.tar.gz]): Could not look up qualified variable 'deploy::tempdir'; class deploy has not been evaluated
Warning: Scope(Deploy::File[atlassian-jira-6.0.tar.gz]): Could not look up qualified variable 'deploy::tempdir'; class deploy has not been evaluated
Warning: Scope(Deploy::File[atlassian-jira-6.0.tar.gz]): Could not look up qualified variable 'deploy::tempdir'; class deploy has not been evaluated
Warning: Scope(Deploy::File[atlassian-jira-6.0.tar.gz]): Could not look up qualified variable 'deploy::tempdir'; class deploy has not been evaluated
Warning: Scope(Deploy::File[atlassian-jira-6.0.tar.gz]): Could not look up qualified variable 'deploy::tempdir'; class deploy has not been evaluated
Notice: Compiled catalog for localhost.localdomain in environment production in 1.38 seconds
Error: Parameter unless failed on Exec[download_atlassian-jira-6.0.tar.gz]: 'test -d /opt/jira/atlassian-jira-6.0-standalone' is not qualified and no path was specified. Please qualify the command or specify a path. at /etc/puppet/modules/deploy/manifests/file.pp:133
Wrapped exception:
'test -d /opt/jira/atlassian-jira-6.0-standalone' is not qualified and no path was specified. Please qualify the command or specify a path.

What I am doing wrong?

Please support the current debian stable by using a systemd start script.

Add tests for oracle database

Hello,

I'm a new user of this Puppet-JIRA module.
Making a quick overview of this module, find below my question about it :

• How do you proceed with all addons contained in JIRA.
• How do you proceed for any upgrade from one existing JIRA instance not managed by Puppet to a new one managed by puppet.
• How do you manage further Jira upgrade.

Thanks by advance for any feedback on above point !

Fred

Puppet is unable to pull the file because of a 404 error, is there a workaround or am I doing something wrong?

Notice: /Stage[main]/Jira::Mysql_connector/Staging::File[mysql-connector-java-5.1.34.tar.gz]/Exec[/opt/staging/jira/mysql-connector-java-5.1.34.tar.gz]/returns: curl: (22) The requested URL returned error: 404 Not Found
Error: curl -f -L -o /opt/staging/jira/mysql-connector-java-5.1.34.tar.gz http://cdn.mysql.com/Downloads/Connector-J/mysql-connector-java-5.1.34.tar.gz returned 22 instead of one of [0]

Getting an occasional race condition stopping the service during JIRA upgrades. Need to add a check in jira.erb after the call to jira-stop.sh to make sure that the JIRA JVM has been shut down, using kill if necessary after a time wait.

service jira status
fails because the script can not find jps in /bin

Workaround:

ln -s /usr/bin/jps /bin/jps

Commit 47226b0 enables systemd support for Debian >= 8 based on osfamily and operatingsystemmajrelease, but this breaks ubuntu, where osfamily == 'Debian' and operatingsystemmajrelease is based on the year.

puppet-staging should replace my puppet-deploy module. It has better tests and support etc.

Possible workaround to start JIRA and still leave users default login shell to /bin/false is define shell in user.sh..erb.

# START INSTALLER MAGIC ! DO NOT EDIT !
JIRA_USER="<%= scope.lookupvar('jira::user') %>" # user created by puppet
SHELL="/bin/bash"
# # END INSTALLER MAGIC ! DO NOT EDIT !

export JIRA_USER SHELL

JIRA 6.2.6
Centos 6.5

All parameters should be validated.

Although its going to make a huge mess in the init.pp

Hello, I was wondering if it'd be possible for us to figure out a way to support RVM installations of Ruby and Facter? I'd add support into the template file myself but I'm really not sure how to tell it to check for that.

As it is I've got a custom init.d script with the line:
OS=/usr/local/rvm/bin/bootup_facter osfamily

Since facter is required I'm not sure how to resolve this in a clean, agnostic manner. If anyone has a suggestion then I can code it up and put in a pull request.

Hi,

I am facing an issue while using this module. Following is the Error :

Error: Could not autoload puppet/parser/functions/scope_defaults: /tmp/ki
tchen/modules/staging/lib/puppet/parser/functions/scope_defaults.rb:2: syntax er
ror, unexpected ':', expecting ')'
newfunction(:scope_defaults, type: :rvalue, doc: <<-EOS
^
/tmp/kitchen/modules/staging/lib/puppet/parser/functions/scope_defaults.r
b:6: syntax error, unexpected ')', expecting kEND
) do |arguments|

Could you please help me to solve this error.

Thanks & Regards
Dharmender

Currently it is not possible to set the session timeout using the module. This setting can be altered in the web.xml file, which is currently not managed. The way I see it there are two options for adding this feature:

1. Use a template, like the server.xml file is created
2. Manage the file with Augeas

In this particular case, as web.xml is quite a large file and not really mend to be edited (as shown in the documentation below), I think option 2 would be most suited.

More information:
https://confluence.atlassian.com/display/JIRAKB/How+to+change+the+default+session+timeout

Make jira users shell configurable.

Need to create oracle dbconfig.xml template and then config.pp check.
Populate the jira.yaml with examples.

We need to remove the recurse => true on the jira home directory. When you have a few thousand attachments it can take the puppet run very long to complete.

file { $jira::homedir:
ensure => 'directory',
owner => $jira::user,
group => $jira::group,
recurse => true,
} ->

Hi,
the bundled tomcat will not start because of a deprecated class in server.xml.erb.

<!--Initialize Jasper prior to webapps are loaded. Documentation at /docs/jasper-howto.html --> <Listener className="org.apache.catalina.core.JasperListener"/>
Just remove it from template server.xml.erb to be compatible.

We need to add beaker tests to make it easier to support more operating systems.

Add support for

• Scientific Linux 5/6
• Debian 6/7
• SLES
• OracleLinux 5/6

I suspect it will work for all of the above, but we wont know without testing it.

This question probably leaves much to be desired, and may be resolved simply with some puppet-fu.

We were receiving errors when starting JIRA in regards to a lack of mysql drivers. We specified the driver in the dbdriver parameter as com.mysql.jdbc.Driver, but still ended up needing to add a driver(.jar) file to <install_directory>/lib/. Due to the fact that JIRA module declares the directory where this needs to be placed, we can't place the file in the right place before running the JIRA module. We do it afterwards then, but by the time we've placed the driver in the right place, JIRA has finished starting without that required file and is displaying a JIRALocked page. So we are forced to stop JIRA, place the file, and start JIRA again. But this means that our nightly puppet runs bounce our JIRA instance. This could be solved by not needing to add the mysql driver, or by having a good way to ensure the service is running at the very end of the puppet run.

Any thoughts?

Can you please add SSL support?

New line needs to be added to the dbconfig.xml file when using MSSQL

<validation-query>select 1</validation-query>

More information here: https://jira.atlassian.com/browse/JRA-59768

Hi,

The module downloads the file as the puppet user (in this case root) and then attempts to untar the module as the jira user. This fails if the server is hardened and restricts permissions on downloaded files. We have to work around this by adding the following heira:

system::execs:
    chown_jira_tarball:
        command: /bin/chown -R jira:jira /opt/staging/
        unless: /usr/bin/stat -c "%U:%G" /opt/staging/jira/atlassian-jira-6.4.2.tar.gz | /bin/grep jira:jira
        require: Staging::File[atlassian-jira-6.4.2.tar.gz]
        before: Exec[extract atlassian-jira-6.4.2.tar.gz]

You'll note this has to reference the version-specific file so when attempting any upgrade you have to change these names as well.

It would be good if the module handled this itself by explicitly ensuring the archive permision are correct before attempting the extract.

This is also the case for confluence and I'll raise it there as well.

The module should verify the checksum of the downloaded JIRA archive in order to make sure it has not been manipulated. The puppet-archive module provides this functionality. IMHO, no module should download artifacts from external sources without ensuring the file's integrity.

As a workaround, the following code could be used

file { "/opt/staging/jira/atlassian-jira-${version}.tar.gz.sha256":
  content => "${checksum} *atlassian-jira-${version}.tar.gz"
}

exec { "/usr/bin/sha256sum -c atlassian-jira-${version}.tar.gz.sha256":
  cwd         => '/opt/staging/jira',
  refreshonly => true,
  require     => File["/opt/staging/jira/atlassian-jira-${version}.tar.gz.sha256"],
  subscribe   => Staging::File["atlassian-jira-${version}.tar.gz"],
}

On an amazon AMI, $::osfamily is RedHat, but $::operatingsystem is Amazon. the problem is that the $::operatingsystemmajrelease is 2015, when the conditional only looks to see if it is 6 or 7. This results in no 'default' option under RedHat.

The correct defaults for the Amazon AMI are the same as RedHat 6

I'm not sure what the best fix would be... switching to $::operatingsystem instead of $::osfamily and adding an /Amazon/ match, or adding an extra conditional inside of the /RedHat/ $::osfamily.

Right now you have to set three configs in order to accomplish the switching between one database type and another. I think it makes far more sense to change the dbtype and dbdriver values based off of what people set for db.

Hello,

I encountered an issue while testing module under Profile/Role architecture.

/manifests/site.pp:

node 'jira.intranet' {
include role::jira
}

/modules/role/manifests/jira.pp:

class role::jira {
notify { 'This is a JIRA Server role': }
include profile::jira_instance
}

/modules/profile/manifests/jira_instance.pp:

class profile::jira_instance {
notify { 'This is a JIRA instance profile': }

file { '/opt/atlassian':
ensure => 'directory',
}

class { '::jira':
javahome => '/opt/java',
}

include ::jira::facts
}

Puppet returns:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Could not find class staging for jira.intranet on node jira.intranet

Is it a bug, or just I am doing something wrong?

Hey there,

i become desperate with die jira-module.
How will jira write in the created Database "jira". In my case the used parameteres are only used for the dbconfig.xml. If I watch the MySQL DB, it is empty. And then I tried the config.sh from the bin-directory. There I saw that Jira is still using the default Database. If I change the DB-settings in this config jira will work. But this should work as default in my opinion.

It would be nice if someone could support me with my puppet-manifest which looks like this:

class { 'jira':
         version     => '6.3.13',
         installdir  => '/opt/atlassian-jira',
         homedir     => '/var/atlassian-jira/jira-home',
         user        => 'jira',
         group       => 'root',
         db => 'mysql',
         dbtype => 'mysql',
         dbuser => 'jira',
         dbname => 'jira',
         dbpassword  => 'test',
         dbserver    => 'localhost',
         javahome    => '/opt/java/jdk1.7.0_21/',
         mysql_connector_URL => 'https://dev.mysql.com/downloads/file/?id=460362',
         proxy          => {
            scheme       => 'https',
            proxyName    => 'localhost',
            proxyPort    => '8443',
         }
    }

Greetings,
Florian

Hello,

is it possible to redirect HTTP requests to HTTPS using this module?

Running JIRA behind an Apache reverse proxy enables the usage of AJP to do all communication via the AJP rather than HTTP. Unfortunately, the module still requires to configure the regular tomcat HTTP connector.

Being able to disable the HTTP connector and only use the AJP one would make the configuration a bit cleaner.

In the class params for jira::facts you default $port to $jira::tomcatPort however this variable is not accessible from jira::facts so it defaults to nothing and I get the error Fact file /etc/facter/facts.d/jira_facts.rb was parsed but returned an empty data set. I know I can override it when declaring the class, but its a bug nonetheless.

class jira::facts(
  $ensure = 'present',
  $port   = $jira::tomcatPort,
  $uri    = '127.0.0.1',
) {

Add tests for Microsoft SQL

the changes described in the Integrating Jira with Apache using SSL wiki page aren't managed by the module, and probably should be.

As it is currently, server.xml needs to be tweaked with every Jira upgrade.

'strip' parameter of staging archive is unsupported with zip files. Sometimes corporate environments (environments) will have the zip archive available and the tar.gz archive not.

In order to use the zip archive with this module, one has to workaround the lack of strip support in staging for zip archives.

Does the module support upgrading to v7 yet? If not are there any plans to support v7 in the near future?

Due to the way the jvm arguments are passed in, JIRA doesn't parse them correctly. The JVM handles them just fine, but JIRA doesn't understand them properly (as I understand it). If you look at the support ticket here, you can see that they want them delimited with semi-colons. It appears to be a harmless error, but would help clean up a consistent log WARN.

JVM_REQUIRED_ARGS="-Djava.awt.headless=true -Datlassian.standalone=JIRA -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true -Dmail.mime.decodeparameters=true"

Something is wrong in server.xml.erb:

<% if @proxy -%>
  <% @proxy.sort.each do |key,value| -%>
    <%= key %> = <%= "\'#{value}\'" %>
  <% end -%>
<% end -%>

Despite setting the parameter 'proxy' it will not be persisted in server.xml

Error: curl  -f -L -o /opt/staging/jira/atlassian-jira-7.0.5.tar.gz http://www.atlassian.com/software/jira/downloads/binary//atlassian-jira-7.0.5.tar.gz returned 22 instead of one of [0]
Error: /Stage[main]/Jira::Install/Staging::File[atlassian-jira-7.0.5.tar.gz]/Exec[/opt/staging/jira/atlassian-jira-7.0.5.tar.gz]/returns: change from notrun to 0 failed: curl  -f -L -o /opt/staging/jira/atlassian-jira-7.0.5.tar.gz http://www.atlassian.com/software/jira/downloads/binary//atlassian-jira-7.0.5.tar.gz returned 22 instead of one of [0]

Should be https://downloads.atlassian.com/software/jira/downloads/atlassian-jira-software-7.0.5-jira-7.0.5-x64.bin