When using this module on Debian wheezy the useradd command fails with
Error: Could not create user stash: Execution of '/usr/sbin/useradd -g stash -c Stash daemon account -d /opt/atlassian/application-data/stash-home -p * -s /bin/bash -m stash' returned 12: useradd: cannot create directory /opt/atlassian/application-data/stash-home

I think this is because the useradd does not use mkdir -p.
After creating the subfolders with mkdir -p /opt/atlassian/application-data it seems to work

Maybe -m and -b will help with useradd

root@host:/opt# uname -a Linux host 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u1 x86_64 GNU/Linux

https://confluence.atlassian.com/bitbucketserver/bitbucket-server-5-0-release-notes-889528342.html

If your using Puppet Enterprise, the github version of this module can cause you to get errors on the console every time you run puppet/facter that look like this:

# puppet agent --test
/etc/facter/facts.d/stash_facts.rb:6:in `require': no such file to load -- json (LoadError)
    from /etc/facter/facts.d/stash_facts.rb:6
Info: Retrieving plugin
/etc/facter/facts.d/stash_facts.rb:6:in `require': no such file to load -- json (LoadError)
    from /etc/facter/facts.d/stash_facts.rb:6

The reason for this is that Puppet Enterprise provides its own Ruby environment with an executable at /opt/puppet/bin/ruby in addition to whatever is already installed on the system. If your system is using an older version of Ruby, its likely that facter will generate the errors above when processing the facts installed by this module

When using choosing to have puppet manage the stash service, the service isn't started until puppet has run because the service definition doesn't ask it to.

Keep getting permission denied when trying to run staging::extract to untar stash file that was downloaded in /opt/staging/stash directory.

Currently 'enable' and 'ensure' are hardcoded (unlike Jira module).

The url structure appears to have changed to this:

https://maven.atlassian.com/public/com/atlassian/stash/backup/stash-backup-distribution/<version>/stash-backup-distribution-<version>.zip

on ubuntu 12.04 - using hashicorp/precise64 image from vagrant

during start, getting the message:

root@stash1:~# service stash start 
Starting stash: To run Stash in the foreground, start the server with start-stash.sh -fg
Starting Atlassian Stash as dedicated user stash 


Success! You can now use Stash at the following address:

http://localhost:7990/

If you cannot access Stash at the above location within 3 minutes, or encounter any other issues starting or stopping Atlassian Stash, please see the troubleshooting guide at:

https://confluence.atlassian.com/display/STASHKB/Troubleshooting+Installation


touch: cannot touch `/var/lock/subsys/stash': No such file or directory

first thing I noticed is the use of /var/lock/subsys which doesn't appear to be common ubuntu? see stack exchange

From atlassian:

Starting with Stash 3.8, we removed the permgen.sh script that checked if PermGen was supported (it's been removed in Java 8). We then made the following changes to setenv.sh:
setenv.sh Stash 3.7
JAVA_OPTS="-Xms${JVM_MINIMUM_MEMORY} -Xmx${JVM_MAXIMUM_MEMORY} ${JMX_OPTS} ${JAVA_OPTS} ${JVM_REQUIRED_ARGS} ${JVM_SUPPORT_RECOMMENDED_ARGS} ${STASH_HOME_MINUSD}"

PermGen size needs to be increased if encountering OutOfMemoryError: PermGen problems. Specifying PermGen size is

not valid on IBM JDKs

STASH_MAX_PERM_SIZE=256m
if [ -f "${PRGDIR}/permgen.sh" ]; then
echo "Detecting JVM PermGen support..."
. "${PRGDIR}/permgen.sh"
if [ $JAVA_PERMGEN_SUPPORTED = "true" ]; then
echo "PermGen switch is supported. Setting to ${STASH_MAX_PERM_SIZE}\n"
JAVA_OPTS="-XX:MaxPermSize=${STASH_MAX_PERM_SIZE} ${JAVA_OPTS}"
else
echo "PermGen switch is NOT supported and will NOT be set automatically.\n"
fi
fi
setenv.sh Stash 3.8
JAVA_OPTS="-Xms${JVM_MINIMUM_MEMORY} -Xmx${JVM_MAXIMUM_MEMORY} ${JAVA_OPTS} ${JVM_REQUIRED_ARGS} ${JVM_SUPPORT_RECOMMENDED_ARGS} ${STASH_HOME_MINUSD}"

PermGen size needs to be increased if encountering OutOfMemoryError: PermGen problems.

MAX_PERM_SIZE=256m
JAVA_OPTS="-XX:MaxPermSize=${MAX_PERM_SIZE} ${JAVA_OPTS}"

export JAVA_OPTS
If setenv.sh was copied over from Stash 3.7, the test to check if using PermGen is allowed always returns false since permgen.sh is no longer there and the PermGen size gets set to the default, which is too small for Stash. Upgrading to JDK 8 would resolve this as well as PermGen is no longer used and replaced with Metaspace.
I've included a fresh copy of setenv.sh from a 3.10 instance that you can use to replace the existing one if it was copied over.

Please support debian (wheezy) explicitely.

Keep up the good work!

When upgrading to version >3.8.0 the stash migration process replaces stash-config.properties when the service is refreshed. It also sets the permissions to 644 as default even though the database password is stored here.

This causes puppet to require two runs to complete the upgrade.

one easy to implement solution is to not refresh the service when the stash-config.properties changes? Another would be to just document the issue in the readme file?

Currently defaults to 7990 in the server.xml. This should be configurable with a parameter.

Consider replacing the deploy module with nanliu/staging, or atleast supporting both.

The template server.xml.erb uses the local proxy variable and should use $stash::proxy instead.

Hi,

it would be great, if this modul has an option to set the context path. For example, if i had the path example.com/stash/, I have to set the context path to /stash.

I see your Jira module has MySQL connector management. Do you have any reservations regarding adding it to this module? If you don't have time, I can work on adding it and testing.

So today i ran into a curious issue:

igalic@levix ~/src/bw/puppet/environments/production (git)-[production] % git push origin production
Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 538 bytes | 0 bytes/s, done.
Total 4 (delta 3), reused 0 (delta 0)
remote: error: file write error (No space left on device)
remote: fatal: unable to write sha1 file
error: unpack failed: unpack-objects abnormal exit
To ssh://[email protected]:7999/infra/puppet-environment.git
 ! [remote rejected] production -> production (unpacker error)
error: failed to push some refs to 'ssh://[email protected]:7999/infra/puppet-environment.git'
1 igalic@levix ~/src/bw/puppet/environments/production (git)-[production] %

the culprit of the remote: error: file write error (No space left on device) was stasbackup.
i think it might be useful to have a cleanup job, that deletes archives older than $n days.

In the backup class the path to java is hardcoded to /usr/bin/java, this should be changed to ${javahome}/bin/java

The documentation for this module indicates that only MySQL and PostgreSQL are supported databases for Stash.

It looks like all that's required is to ensure the JDBC connector is installed as well as setting the database driver/connection options correctly as per the existing My/PostgreSQL setup - or is there something bigger preventing providing Oracle support?

It looks like the backupclientURL has an extra version number appended to the url. The PR #89 fixes it.

Am using the role/profile method for setting up a stash server on minimal install of CentOS 7, here is my role config:

include profile::git
include profile::java
include profile::logstashforwarder
include profile::nginx
include profile::postgresql
include profile::selinux
include profile::stash

Not sure if it's because I'm using the java module to install java but I have to leave set java_home='' otherwise when I try to start the stash service I get an error message about /bin/java/bin/java not being valid:

grep -r "/bin/java/bin/java" /mnt/atlassian/stash/atlassian-stash/atlassian-stash-3.10.2/logs/
/mnt/atlassian/stash/atlassian-stash/atlassian-stash-3.10.2/logs/catalina.out:/mnt/atlassian/stash/atlassian-stash/atlassian-stash-3.10.2/bin/catalina.sh: line 399: /bin/java/bin/java: Not a directory
/mnt/atlassian/stash/atlassian-stash/atlassian-stash-3.10.2/logs/catalina.out:/mnt/atlassian/stash/atlassian-stash/atlassian-stash-3.10.2/bin/catalina.sh: line 399: /bin/java/bin/java: Not a directory
/mnt/atlassian/stash/atlassian-stash/atlassian-stash-3.10.2/logs/catalina.out:/mnt/atlassian/stash/atlassian-stash/atlassian-stash-3.10.2/bin/catalina.sh: line 399: /bin/java/bin/java: Not a directory
/mnt/atlassian/stash/atlassian-stash/atlassian-stash-3.10.2/logs/catalina.out:/mnt/atlassian/stash/atlassian-stash/atlassian-stash-3.10.2/bin/catalina.sh: line 399: /bin/java/bin/java: Not a directory

Not sure if it's because it is being defined in setenv.sh.erb & stash.service.erb but somehow the value is getting doubled.

Rather than hard-coding variables & the template for each of the system properties (i.e. jdbc, setup automation, etc.) would it be possible to make all of the config options able to be managed? You shouldn't have to define defaults for each of the variables as it sounds like they are already in stash and only need to be specified if you want to override the default stash value: https://confluence.atlassian.com/display/STASH/Stash+config+properties

Our devs are wanting to add this but I told them that custom properties weren't supported by the module yet and that I wasn't wanting to snowflake the server for it: https://confluence.atlassian.com/display/STASH/Stash+config+properties#Stashconfigproperties-Pullrequests

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet:

# facter -p puppetversion
4.8.2

• Ruby:

# facter -p ruby
{
  platform => "x86_64-linux",
  sitedir => "/opt/puppetlabs/puppet/lib/ruby/site_ruby/2.1.0",
  version => "2.1.9"
}

• Distribution:

# facter -p os
{
  architecture => "x86_64",
  family => "RedHat",
  hardware => "x86_64",
  name => "CentOS",
  release => {
    full => "7.3.1611",
    major => "7",
    minor => "3"
  },
  selinux => {
    config_mode => "disabled",
    current_mode => "permissive",
    enabled => true,
    enforced => false,
    policy_version => "28"
  }
}

• Module version:

$ egrep '(jira|confluence|stash)' Puppetfile
mod 'puppet-confluence',           '2.3.0'
mod 'puppet-jira',                 '3.1.0'
mod 'puppet-stash',                '2.0.0'

How to reproduce (e.g Puppet code you use)

# Manage a suite of Atlassian applications
class profile::atlassian(
  Array            $packages             = [],
  Boolean          $manage_ipv4_firewall = true,
  Boolean          $manage_ipv6_firewall = true,
  Optional[String] $ipv4_firewall_chain  = undef,
  Optional[String] $ipv6_firewall_chain  = undef,
) {
  # This is where we can install Oracle Java and anything else we need.
  # Consult Hiera for pertinent information.
  if !empty($packages) { ensure_packages($packages) }

  include confluence
  include jira,jira::facts
  include stash,stash::facts,stash::gc

  $fw_defaults = {
    proto => 'tcp',
    dport => [
      $confluence::tomcat_port,
      $jira::tomcat_port,
      $stash::tomcat_port,
    ],
  }

  # Poke IPv4 firewall holes for reverse-proxy
  if $manage_ipv4_firewall {
    firewall { 'IPv4 Atlassian ports':
      * => $fw_defaults + { chain => $ipv4_firewall_chain, },
    }
  }
  # Poke IPv6 firewall holes for reverse-proxy
  if $manage_ipv4_firewall {
    firewall { 'IPv6 Atlassian ports':
      * => $fw_defaults + {
        chain    => $ipv4_firewall_chain,
        provider => 'ip6tables',
      },
    }
  }
}

What are you seeing

I would like to install Jira/Stash/Confluence on the same host, but the systemd exec clause in the Jira and Stash modules have the same resource title:

• https://github.com/voxpupuli/puppet-stash/blob/master/manifests/service.pp#L29-L34
• https://github.com/voxpupuli/puppet-jira/blob/master/manifests/service.pp#L37-L41

What behaviour did you expect instead

Change the resource title names to be module-specific, or use ensure_resource() to work wround the issue. Not sure which you'd like...

Output log

# puppet agent -t
Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Resource Statement, Duplicate declaration: Exec[refresh_systemd] is already declared in file /etc/puppetlabs/code/environments/production/modules/jira/manifests/service.pp:43; cannot redeclare at /etc/puppetlabs/code/environments/production/modules/stash/manifests/service.pp:29 at /etc/puppetlabs/code/environments/production/modules/stash/manifests/service.pp:29:7 on node stswebapp0.ucsd.edu
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

Any additional information you'd like to impart

https://github.com/voxpupuli/puppet-confluence/blob/master/manifests/service.pp does not (yet?) have this issue, but I would obviously recommend thinking about it.

Cheers.

creating a user with a non existant homedir results in an error with useradd

err: /User[stash]/ensure: change from absent to present failed: Could not create user stash: Execution of '/usr/sbin/useradd -s /bin/true -d /opt/atlassian/application-data/stash-home -c Stash daemon account -m stash' returned 12: useradd: cannot create directory /opt/atlassian/application-data/stash-home

looking at the code, the file resource needs the user to exist, but the user resource needs the file to exist.

 user { $stash::user:
    comment          => 'Stash daemon account',
    shell            => '/bin/true',
    home             => $stash::homedir,
    password         => '*',
    password_min_age => '0',
    password_max_age => '99999',
    managehome       => true,
    uid              => $stash::uid,
    gid              => $stash::gid,
  } ->
#...
file { $stash::homedir:
    ensure  => 'directory',
    owner   => $stash::user,
    group   => $stash::group,
  }

Stash has been renamed to Bitbucket Server, it likely will no longer work with the module as is.

We should add support for Bitbucket Server, and attempt remain backward compatible with with stash 3.x

I think that I can try to work on this if I get time but am putting it here just to document. The deletion of backups probably shouldn't be handled by puppet but rather a script stored locally. We had to disable the puppet agent on our stash server while troubleshooting the setenv.sh template issue and the backups almost filled the hard drive.

The setenv.sh template is not compatible with 3.10.2. Upgraded our stash server from 2.12.0 to 3.10.2 over the weekend and couldn't get it to run reliably as the java load would shoot up and not go back down until stash crashed. Submitted a ticket with atlassian and after reviewing the support packet they said that the setenv.sh file we were trying to use (from this module) was no longer compatible after 3.7.

https://confluence.atlassian.com/display/STASHKB/Stash+crashes+due+to+java.lang.OutOfMemoryError+PermGen+Space+Error

Make the stash users shell configurable.
Make the default shell /bin/true and not /bin/bash.

No matter what value I give to backup_keep_age it never seems to run!
I have stash::backup_keep_age: '5d' set in hiera am I missing something obvious?

when stash user and group have the same name, the installation process will fail with message:

err: /User[stash]/ensure: change from absent to present failed: Could not create user stash: Execution of '/usr/sbin/useradd -s /bin/true -d /opt/atlassian/application-data/stash-home -c Stash daemon account -m stash' returned 9: useradd: group stash exists - if you want to add this user to that group, use -g.

puppet bug - https://projects.puppetlabs.com/issues/19090

Previously, even when installing Stash automatically, you still had to visit the Stash Setup Wizard in the browser to set the admin account, the Base URL and the external database connection, and to add the Stash license.

Now, by specifying all those settings in the Stash config properties file, you can completely install and set up a Stash instance automatically, without manual intervention. Stash will read the file, and apply those settings automatically after launching.

Its documented here:
https://confluence.atlassian.com/display/STASH/Automated+setup+for+Stash

The discussion came up of this module should get archived. Should someone want to keep this module around, just comment here.
If no comments to keep this around arise in the new weeks, we will move forward with archiving.

Stash has moved the server.xml from version 3.8 to ' /shared/server.xml'

I may be missing something in my configuration, but I am getting the following error:
Could not find class staging
When I change to deploy I get an error saying something about invalid type deploy::file

Note: I am using puppet apply and a masterless setup, I am not sure if thats related due to autoloading or similar. But I am not really familiar with the syntax being used in here since I dont see a deploy::file defined type nor do I see a class named staging and its required.

Anybody know what I am missing?

stash::install assigns shell /bin/true to the stash user; this will also cause the init scripts to not work.

https://confluence.atlassian.com/display/STASH/Running+Stash+with+a+dedicated+user

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: All supported versions
• Ruby: All supported versions
• Distribution: All supported distros
• Module version: 2.0.0

How to reproduce (e.g Puppet code you use)

Change product from stash to bitbucket:
stash::product: 'bitbucket'

What are you seeing

When the init script runs it attempts to execute start-stash.sh which is named start-bitbucket.sh on bitbucket server.

What behaviour did you expect instead

It should pull in the variable from the module settings.

Output log

Error: /Stage[main]/Stash::Service/Service[stash]/ensure: change from stopped to running failed: Could not start Service[stash]: Execution of '/sbin/service stash start' returned 127: Starting stash: /etc/init.d/stash: line 55: /opt/grubhub/services/stash_installdir/atlassian-bitbucket-4.14.6/bin/start-stash.sh: No such file or directory

Any additional information you'd like to impart

Incoming fix for this.

Atlassian changed the location of the config files for Stash with version 3.2.0.

A documentation can be found here:
https://confluence.atlassian.com/display/STASHKB/Upgrading+your+Stash+home+directory+for+Stash+3.2+manually

Problem:

stash-config.properties has moved to shared/stash-config.properties. If you upgrade Stash to a version >=3.2.0 or install this version, Stash will migrate the file and copy it to the shared folder. The puppet module will recreate it on next run. If Stash is restarted with both files existing, it refuses to work and assumes the automatic migration to the new version didn't work correctly.

Possible Solution:

According to the version the fact for stash-config.properties should contain the new directory.

@nibalizer @igalic Could you help me with this? I have copied my .travis.yml updates from another module here. But I am not sure what to do about the passwd.

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 4.8.2
• Ruby: 2.3.3
• Distribution: Debian
• Module version: 3.0.0

How to reproduce (e.g Puppet code you use)

Change stash::product to 'bitbucket'.

What are you seeing

It fails to download the backup client.

What behaviour did you expect instead

It should download the backup client

Any additional information you'd like to impart

In manifests/backup.pp the 'file' variable on line 38 takes 'product' as argument inside the string. Replacing #{product} with stash solves this problem for me.

I just did an upgrade of stash to the latest version with this module, and it worked out flawlessly.
I guess we should declare it the new default ;)

we haven't released the module in a while :(

Rather that manage the template files with a static template. Modify them with the augeas provider.

Would it be possible to support the JMX setting in the template et al? There's both the stash JMX as well as the TomCat JMX we'd like to have enabled.

Three things would have to be added:

• CATALINA_OPTS would have to be exported in setenv.sh; this would define the necessary JMX environment variables
• 'jmx.enabled=' would have to be added to stash-config.properties
• an access file would have to be created specifying the 'monitorRole', the path of which would be specified in the aforementioned CATALINA_OPTS variable.

Is this something you'd be interested in supporting?

Affected Puppet, Ruby, OS and module versions/distributions

Not a Puppet issue

How to reproduce (e.g Puppet code you use)

Install recent Bitbucket version

What are you seeing

The Systemd service is able to start, but not to stop the Bitbucket server. I think the reason is inside the wrapped init.d script.

What behaviour did you expect instead

The Service can be started and stopped.

Output log

Any additional information you'd like to impart