This ensures that the standalone deployments directory of TorqueBox/JBoss is owned by the Razor user. This is the correct mode for supporting a single application deployment, and matches our expected use. Signed-off-by: Daniel Pittman <firstname.lastname@example.org>
This reverts the explicit management of file modes through Puppet; that was added in addition to setting the umask to our expected value during unpacking to try and work around sites with more restrictive than "default" umask values. Unfortunately, it doesn't compass the full complexity of permissions; we need to have executable permissions on various files in JBoss, etc, that I don't want to hand-maintain lists of just to work around a problem solved at the source. The umask changes are retained, but the permission management changes backed out. Signed-off-by: Daniel Pittman <email@example.com>
This is an example of how to use `puppet apply` to install razor-server, with a little bit of stuff wrapped around it to make it look less odd, and to try and stop people using it in a way that might really hurt them on the master. Signed-off-by: Daniel Pittman <firstname.lastname@example.org>
This adds an example configuration file for the ISC DHCPd that will make it work smoothly with razor-server. Since we don't automatically configure DHCP operation, this should ease integration for some folks. This is not an example of using Puppet to configure the system, which is left as an example for the reader. Signed-off-by: Daniel Pittman <email@example.com>
This test code was associated with the older version of the Razor module, and as is the nature of "bench" testing system configuration, was dominated by useless assertions about how the module was structured. In the rewrite the specs and other tests became essentially useless, and rather than rewriting the testing to assert that the manifests contained what they contained, they were ignored. Sadly, I didn't back that up by removing the manifest content, which led to user confusion. So sorry to have done that to y'all. Signed-off-by: Daniel Pittman <firstname.lastname@example.org>
Unfortunately, during testing I missed that my init script was binding exclusively to the loopback address -- my hosts file had the hostname mapped to loopback, so it "worked for me". This fixes that, by explicitly binding to the wildcard address when starting the `standalone.sh`. How embarrassing. Thanks to Lucas Harms <email@example.com> for helping with this. Signed-off-by: Daniel Pittman <firstname.lastname@example.org>
One of the earliest steps that needs to be run when deploying Razor is to migrate the database. This is typically done as root, which means that it will create the Sequel/Sinatra log ... as root. That, in turn, caused a failure when starting the application as a less privileged user for the first time. This commit doesn't fix the problem, as such, but it does create the log file during installation, and ensures that the permissions remain correct. This means that we *should* be less likely to encounter this in practice. Eventually we need a better solution inside razor-server, but for now this should ensure first installations are smooth. Thanks to Lucas Harms <email@example.com> for helping with this. Signed-off-by: Daniel Pittman <firstname.lastname@example.org>
This is a major, incompatible update: the razor module will now install the new `razor-server` implementation of Razor, rather than the original implementation. This brings a new and disparate set of dependencies. This module makes no effort to uninstall the older Razor, aiming instead to provide a fresh implementation. Migration is not currently supported either. Signed-off-by: Daniel Pittman <email@example.com>
The Razor module installed two versions of the nodejs `express` package, a toolkit for writing your own web server on top of a basic HTTP accept loop. One was installed in the Razor directory, pinned to an older version, and fairly boringly functional. This is the one that is actually used by Razor. The other was a globally installed "latest" version, which was not actually used, was kind of incompatible with the way Razor build its CGI interface, and was incompatible with older versions of nodejs on, say, Ubuntu 12.04. This just removes the global version: it served no actual purpose, other than violating the nodejs community standards (throw stuff in your private directory, no shared library code), and making Razor more apparently complex. Signed-off-by: Daniel Pittman <firstname.lastname@example.org>
…oviders This change reverts checking for errors in the image provider because the image action of the razor command does not return PSON unlike the other actions. Instead, the image provider now returns the output of the razor command and always succeeds, like before. Ideally, the image provider should look at the return value and raise a Puppet::Error when failing to add an image. However, the razor command always seems to return 0 and the output is awkward to parse. So, the changes to the image provider should be reverted for now until the Razor project is updated accordingly. Closes #133
This change modifies the create and destroy methods in the rz_broker, rz_image, rz_model and rz_policy providers to raise a Puppet::Error when an error occurs. This is achieved by passing the output to the parse method in the PuppetX::PuppetLabs::Razor class. If the output contains a 'response' key, it is returned, if it contains a 'result' key, a Puppet::Error exception is raised with it, otherwise a Puppet::Razor exception is raised with the whole output. The reason for this change is to enable Puppet manifests using Razor resources to actually get an error when the razor command fails. Otherwise, the error is simply ignored and the user has to reverse engineer the problem from the side effects of the failure. Note that this change moves the parse method in PuppetX::PuppetLabs::Razor from being private to public, so that it can be re-used in the providers. Also note that it did not implement the behavior for the rz_tag provider because it is much more complicated, having to potentially manage multiple tags. This can be handled in a separate pull request. This pull request fixes issue #130.
This reverts commit 9ea9092. It turns out that the approach I took to solving the problem, while attractive, is secretly an attractive nuisance. It makes it impossible to actually test anything but the released version of the code and, in the nature of hitting commit, also called a couple of people out to explain why it made their lives miserable also. This brings us back to the previous state, from which I will proceed forward to add tarball support again, and to integrate it in a fashion that doesn't lead to quite the same set of failures.
Pull request #125 removed the ability to specify a git source or revision, along with other changes; this wasn't reflected in the tests. This strips out the attempt to use the git version, which wasn't providing any particular value in any case. Signed-off-by: Daniel Pittman <email@example.com>
This moves away from the previous, legacy, default of installing from git head, in favour of installation from the stable release tar file available on https://downloads.puppetlabs.com/razor Like the packages, this will refuse to install over the top of an existing git deployment; if `/opt/razor/.git` exists the Puppet module will refuse to run. Users should manually remove the directory - or otherwise resolve the conflict. It is safe, and supported, to simply delete the `.git` directory, and then install from tar over the existing git deployment. There should not be any data loss from this. This closes #124. Signed-off-by: Daniel Pittman <firstname.lastname@example.org>
This extends the hacks in the Modulefile to automatically rewrite the contributor list in a stand-alone file. This makes it practical to give public credit to the folks who have contributed to the module without human error dropping some of them. Closes #122. Signed-off-by: Daniel Pittman <email@example.com>
The added cache feature tried to reference a temporary directory that no longer existed; this corrects that bug by excising the additional code. Since this was unused, no ill effects flow from this. Signed-off-by: Daniel Pittman <firstname.lastname@example.org>