Stable Barracuda install not passing DNS test

Have you tried to set the hostname before running Barracuda maybe?
You should use:

_MY_OWNIP=""
_MY_HOSTN=""
_MY_FRONT=""

and allow Barracuda to set it up for you, so hostname and hostname -f will be (both) a FQDN to avoid issues with Aegir requirements.

In general, you shouldn't even touch anything on the clean VPS - just run properly configured Barracuda installer.

Thanks for the detailed report.

I think we should add a better how-to (or maybe even require configuring the DNS MANUAL CONFIG section) to avoid similar issues, when the system has already some dummy hostname based on the provider/host reverse DNS IP names, like it is at Linode, since they are useless and confusing for people who didn't try that before.

Last night the barracuda stable script worked fine for me, then this morning I ran it again and it failed smtp check for port 25, at Linode. Ran it 3x, even pasted in a new script with newly-set variables entered in carefully, all failed.

Next, all I did was change the line from 1.0-boa-T-8.7 to become HEAD and the script runs fine (didn't reformat the disk between these script changes btw)

Am using Debian 6, 64bit. Seems odd, but also confirms the original parent of this thread and might be worth looking into.

@Amstercad

This is unrelated to the original issue. Please open new issue when you experience problem not discussed before.

The SMTP check can fail if:

1. There is temporary problem with network connection to the smtp.postoffice.net server.
2. There is something wrong with dns on your server/network during the install.

But you did something really wrong here - you should never use stable version to install HEAD, as this may lead to unsupported or incomplete install/upgrade later. Please read the docs/INSTALL.txt and docs/UPGRADE.txt to learn how you should use stable and HEAD properly.

We are using version check to deny this not supported use of the script, but sometimes the version number of stable and HEAD is the same and it will allow you to run HEAD install with stable version of the script, but expect issues if you will try that.

I've also noticed that with Linode DNS changes often take forever (i.e. several hours) to update. When I was setting up my BOA on Linode I had similar issues, but when I started from scratch and the DNS settings had been in the system over night, everything worked fine. I have since updated once without issue as well.

I don't know if that helps or not, but I hope so.

Steve

Thanks for sharing, I couldn't figure out why it wasn't working for me either, then I realized I had recently changed DNS entries on my host 6Sync.

Can't get past this on a clean Debian Squeeze install under Bytemark VPS. Instructions are rather lacking - it's not clear from the install documentation what the difference is between the host and front end addresses and how to choose each. It looks like I need to set aside a 'host' domain and subdomains to server hosting, as Barracuda creates subdomains of the host. This isn't possible with the standard hosting service domain of XXXXX.vm.bytemark.co.uk that I've been using for Aegir previously, and also likely requires custom nameserver records as discussed above. I'm going to try setting up appropriate nameserver records now, and will report back if I get it all working. This is a rather big task and potential sticking point though - definitely worth improving documentation on.

Yup, got it working by changing to its own domain with wildcard subdomains on the nameserver. Hit some fairly major documentation snags once the server was actually installed though. Simple stuff, like should I be using the aegir user in this install (yes, by the looks of it), where should I dl platforms to (/var/aegir/platforms), why does drush dl keel over sideways for no good reason (something to do with time limits?), and why can't I restart nginx successfully (because I started with a standard Debian squeeze install that had a live Apache2 server in place). Fingers crossed it all works from here on in!

@DanielJohnston

All your questions are already answered either on the project page, in the configuration comments, Octopus welcome e-mail or online library, linked there.

There are no detailed docs "by design", because one of the main ideas is to keep it simple, but it is expected that you follow what is explained in the project readme.

There are "centralized" docs started in the BOA group on g.d.o for those who prefer to read "classic" docs instead of project page + readme + configuration comments + welcome e-mail + linked library + issue queue, but it is community powered only, so anyone can improve it.

See also:
http://groups.drupal.org/node/163489
http://groups.drupal.org/node/163784

I tried everything with the BARRACUDA script; I made sure my uname -n came back with my FGDN (it did), when I typed hostname, it spit out my FGDN. I tried not entering values in the custom variables in the script but nothing worked, it came back saying the following (ip number and host name has been changed to protect the innocent):
-----------------------------------------------------------------------------------------------------------------------------
* Your custom _MY_OWNIP is set to "38.55.53.150"
* Your custom _MY_HOSTN is set to "hosting.mytest.com"
* Your custom _MY_FRONT is set to "aegir.mytest.com"

* Your _MY_HOSTN and/or _MY_FRONT doesn't match your _MY_OWNIP,
or your hostname is not set properly yet.

* Please add/check correct line in your /etc/hosts file on the server:

$ echo "38.55.53.150 *.hosting.mytest.com aegir.mytest.com" >> /etc/hosts

* Please make sure that below command returns your FQDN hostname "hosting.mytest.com":

$ uname -n
--------------------------------------------------------------------------------------------------

I reviewed the script and I checked out it took out the ip number with ifconfig and also the host and I got the right values back; the only thing I don't have on my system is sipcalc which the script uses and perhaps that's why it fails.

I decided to set DNS_TEST = NO and now its running through the install; I have no idea if it will work yet (because I'm in the middle of the install) but I figure I would post this because I tried everything in the book for 2-3 hours and eventually I gave up. I am using wildcard and I'm using Ubuntu Lucid.

If anyone figures out why this isn't working as it should, I would be very interested in hearing what it was causing the issue; after setting the DNS_TEST to NO, it came back and said the DNS test OK, your FQDN is hosting.mytest.com and it matches your IP 38.55.53.150, so that's is REALLY weird.

/Chris

Closing this as duplicate.

If you are using CNAME and not IN A in your DNS, then check this issue for follow-up: #1248432: BOA install fails when its subdomain has CNAME and not IN A DNS record

I put in my reverse DNS as host.example.com and the install did indeed work

I can confirm this. I was getting DNS errors with Barracuda installs (stable 1.0-boa-T-8.9). I tried several times, again with errors, until I put a Reverse DNS from the IP number of the VPS to its hostname (such as host.example.com). This Reverse DNS was indeed the solution. For example, for a Linode VPS this is done in the Remote Access section of the Linode Manager.

About the duplicate issue, I was already using A records and not any CNAME record, so this was not the problem.

I would suggest to correct the current "Reverse dns is _not_ required", since on the contrary this is sometimes the solution, at least in cases like these with Linode.

@juan_g reverse DNS is *not* required. If that helped for you, it only means there is still some problem in your DNS (or in the BOA dns check logic), so it could be helpful to get more details on your setup so we can debug it properly. Please open new issue, however, as it is not directly related to the bug we fixed here.

I closed this as duplicate, because the initial report in this issue was related to CNAME records, not lack of (unneeded) reverse DNS.

If you don't use CNAME and it still doesn't work for you, the issue is elsewhere.

Ah, I just realized you experienced this issue with 1.0-boa-T-8.9. It is expected as we fixed the issue in head, now released as 1.0-boa-T-8.10.

Just to confirm that again: we use Linode for testing, its reverse DNS is Linode default, and it never caused any issues. Since 1.0-boa-T-8.10 it just works if you use either IN A or CNAME records for your FQDN hostname in *your* domain (not Linode hostname, which you don't control).

Ah, sorry, that's correct. The problem with the DNS check happened a few weeks ago. I didn't know it had been so quickly fixed.

It was my only problem with the Barracuda install. I'm realizing now that maybe it came from a reverse DNS that -if I remember correctly- I had from some time ago with a different hostname (not the Linode default). Or maybe not, because I rebuilt the VPS from scratch for each try (not sure if this affects the reverse DNS). In any case, after that reverse DNS correction (for my case and the past version), it seems to we working fine.

Thank you very much for this software, I think it can be a truly remarkable help for the Drupal community.

Эффективная наружная реклама, недорого

Разработка и дизайн сайта.