There's a bug in Bitbucket 4.6.0. It's trying to write a pid file to the installation directory. How embarrassment! Anyone know how to work around this easily (without compromising security by allowing write access)?
So looks like the only way is to edit bin/start-search.sh. There's two places where it gets set like this:
piddir=$(cd "$PRGDIR" && pwd)
Changing it to:
and restarting bitbucket has restored the search functionality. Obviously you should use the correct location for your data directory, as appropriate. Or even better, set it up to use the standard /var/run location.
I've been attempting to replicate your issue today and I'm interested in your setup of the Bitbucket installation directory.
As it currently exists, Bitbucket requires access to the
logs directories in the installation directory. We do expect this folder to be writeable by the
atlbitbucket user as documented in the guidance page. You do not need to provide any other users with this permission, so
atlbitbucket can happily be the only user with write permissions to these folders.
If you can fill me in on your folder permission setup, and expectations here I'd love to gather the feedback so we can take that into consideration.
So in my opinion, it's a security issue if a daemon has write access to its own executable. So I don't think it's a good idea if this is what you recommend in the guidelines. However, I understand that on desktops and in dev environments it's much easier to set it up all in one directory, and that those used to Windows are used to this sort of setup.
If you read the bin/start-bitbucket.sh script (or, as of 4.6.0, the bin/set-bitbucket-home.sh script), it says "One way to set the BITBUCKET_HOME path is here via this variable. Simply uncomment it and set a valid path like /bitbucket/home. You can of course set it outside in the command terminal; that will also work."
So that's what I'm doing: I set BITBUCKET_HOME before calling start-bitbucket.sh. I'm also taking the liberty of setting the umask (so other system users can't see git's files) and CATALINA_BASE and running as a non-privileged user. I set the CATALINA_BASE since that is the recommended way to run tomcat – with a separate home and base.
export BITBUCKET_HOME=/var/lib/git export CATALINA_BASE=/var/lib/stash umask 0027
I had to make a symlink from /var/lib/stash/conf -> /usr/local/stash/conf to get it to work. A copy would have also worked since I do patch the server.xml, but I'd like to keep the conf as close to pristine as possible.
I also set /usr/local/stash to be a symlink to /usr/local/atlassian-bitbucket-current-version.
I have an update script that unpacks the new archive with owner root, patches the server.xml (to configure the connectors), runs the stop script, does a
ln -nfs to the newly-unpacked directory and runs the start script. The non-privileged user (
git) I run the scripts under has only permission to write to /var/lib/git and /var/lib/stash:
pdr@gilbert:~$ ls -ald /var/lib/stash /var/lib/git /usr/local/stash /usr/local/*bitbucket* drwxr-xr-x 12 root staff 4096 Apr 13 04:16 /usr/local/atlassian-bitbucket-4.5.2 drwxr-xr-x 13 root staff 4096 May 9 06:36 /usr/local/atlassian-bitbucket-4.6.0 lrwxrwxrwx 1 root staff 25 May 10 12:20 /usr/local/stash -> atlassian-bitbucket-4.6.0 drwxr-x--x 16 git git 4096 May 10 13:18 /var/lib/git drwxr-x--- 6 git git 4096 May 13 2014 /var/lib/stash
/var/lib/git and /var/lib/stash probably could have been put together, but that's just how it is since I set it up originally and I haven't had a reason to change it. I really only use /var/lib/xyz and /usr/local/xyz because that is where I expect to find them, although I still always first look in /var/log for the log files.
So I hope that explains the setup somewhat. I use a very similar approach for other installations that don't come with a native system package (.deb, .rpm, etc), including Jira, Confluence and Bamboo. I think at some point, I'll create native packages to simplify the puppet configuration and better conform to the FHS by putting the files in the right places under /usr and configuring the logs to go to /var/log and the pid files to go to /var/run, etc, but that's a job for another day.
Thanks and best regards,
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
After spinning my wheels trying to get organized enough to write a book for National Novel Writing Month (NaNoWriMo) I took my affinity for Atlassian products from my work life and decided to tr...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs