Open G4bzh opened 8 years ago
Not sure why are you trying to run it via Puppet on localhost, in the first place? Also, not sure if this is due to something in the environment caused by using Puppet, or because you are trying to install it on localhost using public mode. The localhost mode is still considered as needing some debugging, so it is marked as experimental, and using public mode to avoid those problems may not always work as you have expected.
Also, what is the OS used?
OS is debian jessie The install occurs on a VM (with correct fqdn) not on localhost.
OK, these lines confused me:
The following settings will be used:
Aegir frontend URL: o1.barracuda02.local
Master server FQDN: barracuda02.local
But the first question remains: why are you running it with Puppet and not directly, as intended?
We are using massively IT automation and Puppet is our main tool. All of ours server are configured through puppet, which allows us to "spawn" a production-ready server without human intervention. We are using aegir and your BOA env is quite interesting for us. We have tested it successfully and now we are trying to automate it, just like our other servers
I guess that the issue is due to Puppet because it works directly, but i just cant figure out why. That's why i ask you the question, in case you have a hint :)
Thanks, that makes sense, although we still need to speed it up and use pre-built packages, before it could be considered as truly useful in such scenario.
Anyway, the fix should be trivial, we just need to figure out what exactly doesn't work when run via Puppet.
@G4bzh -- Can you share the Puppet recipe you are trying to use to install BOA? This could help in debugging this further.
Something as simple as that will fail to install octopus (although it installs barracuda successfully) in my setup :
class boa
{
exec
{
"BOA_INSTALL" :
command => "/bin/bash /tmp/BOA.sh.txt",
returns => [0,1],
creates => "/opt/local/bin/boa",
}
exec
{
"AEGIR_INSTALL":
command => "/opt/local/bin/boa in-stable public $my_fqdn $my_email none | tee aegir.log",
timeout => 0,
require => [Exec["BOA_INSTALL"]],
}
}
Hi there,
I've made some progress ! Due to the fact that we can install octopus directly, we've started to dig around the way Puppet launches the installer. We guess that some env variable was not set or something like that after barracuda was successfully installed.
So we decide to split the install : barracuda first then octopus. Octopus installer is then launched simulating a new root bash session (combining su
and bash --login
) and it works now. The "puppet exec" will look like :
exec
{
"OCTOPUS_INSTALL":
command => "/bin/su -l root -c \"/bin/bash --login -c \\\"/opt/local/bin/boa in-octopus $my_email o1 none stable\\\"\"",
provider => "posix",
timeout => 0,
}
We will clean up our tests and make a final review here asap. Sounds good !
Gab
Looks like an acceptable workaround, although finding and fixing the real problem would be better.
Hi,
This workaround is fully functionnal.
The main drawback is that we force the first install (barracuda + octopus) to crash when it comes to install octopus, by specifying bad parameters in cnf file. Then we launch another octopus install with the method explained in my previous comment.
Maybe there's a way to install barracuda only. I guess that the boa script install barracuda independantly and then an octopus instance. If we can simulate this behaviour in Puppet, problem will be fully and cleanly solved :) !
Hi there,
I've got a little problem. We are using Puppet in our env and we're trying to setup BOA with it. For the moment, we simply launch "boa in-stable public ..." throught a 'puppet exec'. The barracuda part goes just fine but the octopus failed with that message:
In the install log, we can see mysql relatives messages :
Indeed the 'o1' user doesn't exist in the database but we can't figure out why. The .my.cnf file is correctly dropped and we can connect to the database via 'mysql -u root'
Moreover, when we launch the same command ("boa in-stable public ...") directly, octopus installation is successfull, so it doensn't seem to be a configuration issue.
Any ideas ?
Thanks
Gab