I don't really know where to log this, but I've been testing tonight and I have a bit of a problem with this assumption:

http://git.aegirproject.org/?p=provision.git;a=commit;h=7a3fc352d9c6cae7...

"don't prompt for the FQDN

it's usually the same as the URL, and indeed we default to that now"

This causes problems, if your server's fqdn is 'www-1.mig5-labs.net' and you want to access your aegir frontend via 'aegir.mig5-labs.net'.

If I enter the domain name as 'aegir.mig5-labs.net', overriding the default-discovered FQDN of www-1.mig5-labs.net, (and incidentally set --aegir_db_host=localhost, not sure if that really is relevant here), I get a password prompt as the aegir system tries to ssh/rsync to itself.

aegir:~# su -s /bin/sh aegir -c "sh install.sh --aegir_db_host=localhost"
==> Installing drush in /var/aegir
--2010-11-20 11:19:25--  http://ftp.drupal.org/files/projects/drush-6.x-3.3.tar.gz
Resolving ftp.drupal.org... 140.211.166.134
Connecting to ftp.drupal.org|140.211.166.134|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 174892 (171K) [application/x-gzip]
Saving to: `drush-6.x-3.3.tar.gz'

100%[==============================================================================================================================>] 174,892      392K/s   in 0.4s

2010-11-20 11:19:25 (392 KB/s) - `drush-6.x-3.3.tar.gz' saved [174892/174892]

==> Drush seems to be functioning properly
==> Installing provision backend in /var/aegir/.drush
Initialized empty Git repository in /var/aegir/.drush/provision/.git/
remote: Counting objects: 7631, done.
remote: Compressing objects: 100% (4905/4905), done.
remote: Total 7631 (delta 5558), reused 3630 (delta 2660)
Receiving objects: 100% (7631/7631), 1.18 MiB | 522 KiB/s, done.
Resolving deltas: 100% (5558/5558), done.
==> Installing the frontend
Aegir HEAD automated install script
==============================================================================
Some settings have not been provided and will now be prompted.
Don't worry: you will get to review those settings after the final install
Aegir frontend URL [www-1.mig5-labs.net]: aegir.mig5-labs.net
MySQL privileged user ("root") password: 
Admin user e-mail [webmaster@aegir.mig5-labs.net]: miguel.jacq@gmail.com

This script will operate the following changes in your system:

1. Create server-level configuration directories
2. Download drush_make
3. Create the Hostmaster frontend platform
4. Install the frontend site
5. Setup the dispatcher (a user cron job)

We are making the following assumptions:
 * you have read INSTALL.txt and prepared the platform accordingly
 * the FQDN of this machine is valid and resolves
 * you are executing this script as your "aegir" user

The following settings will be used:
 Aegir frontend URL: aegir.mig5-labs.net
 Master server FQDN: aegir.mig5-labs.net
 Aegir root: /var/aegir
 Aegir user: aegir
 Web group: www-data
 Web server: apache
 Aegir DB host: localhost
 Aegir DB user: root
 Aegir DB password: <prompted>
 Drush make version: 6.x-2.0-beta9
 Aegir version: HEAD
 Aegir platform path: /var/aegir/hostmaster-HEAD
 Aegir makefile: /var/aegir/.drush/provision/aegir.make
 Client email: miguel.jacq@gmail.com

Do you really want to proceed with the install (y/n): y
The authenticity of host 'aegir.mig5-labs.net (173.203.117.81)' can't be established.
RSA key fingerprint is a5:56:37:aa:cc:0c:2b:02:94:35:f6:82:7d:79:6a:1e.
Are you sure you want to continue connecting (yes/no)? yes
aegir@aegir.mig5-labs.net's password:

I understand this isn't the 'usual' configuration but we shouldn't assume people's server's hostname matches their frontend URL - we do support virtualhosts after all.

Alternatively maybe this logic just needs fixing somewhere in provision to stop it thinking it's a remote web server.

Comments

anarcat’s picture

anarcat CreditAttribution: anarcat commented
Status: Active » Needs review

Well, that is something I would consider normal: if you provide a hostname that is not local, it will try to SSH into it. The fact that the FQDN defaults to the site name is the thing I changed here, and it's still overridable (through --aegir_host).

I was getting tired of getting asked the same question twice... Maybe we can add this to the "assumptions"? ("The FQDN is local" or something...)

adrian’s picture

adrian CreditAttribution: adrian commented

i have never had a situation where the hostname == the site's domain name. ever.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

While I'm forcing FQDN hostname and URL frontend in Barracuda and Octopus, because I want to be fully compatible with remote stuff/heads, without any "localhost everywhere surprises", I agree it *could* be useful to just allow people to install Aegir with locally listening MySQL, without too much pain associated with that "wtf fqdn!?" syndrome.

At the same time I believe we shouldn't assume that Aegir frontend == hostname. It should be prompted or just required as it was before and people are probably already used to do that.

The point is (from my experience), that you should be able to separate hostname and the frontend URL *by default*, because the frontend can be changed (alias added etc) while hostname must not be changed (never ever) after the Aegir has been installed, or you will break the install completely (due to grants using hostname).

I have seen that a few times already - people are trying to change the hostname because they believe it is allowed and easy as adding an alias to the frontend. And they are wrong. It isn't that simple.

What is the reason to assume that frontend could/should match the hostname, after all? It is enough Barracuda is doing just that by default ;)

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Status: Needs review » Needs work

I'd rather that we didn't add it to the assumptions, because I feel it's the wrong assumption.

I agree with Adrian here - I have hostnames that almost always differ from the aegir frontend domain.

if you provide a hostname that is not local, it will try to SSH into it.

That's the bug here: even though they resolved to the same IP, which was the same eth0 interface on the server, *something* is wrong with the logic if it makes it try and rsync/SSH to itself.

I'm glad it's a configurable option but I don't think the majority case is that where the aegir frontend URL matches the hostname/FQDN of the server. I think the FQDN prompt should be skipped *if* --aegir_host was provided.

anarcat’s picture

anarcat CreditAttribution: anarcat commented

So we have three things here:

a) the fact that aegir does SSH on the external interface because it's not considered "local" (which could be considered a bug)
b) whether we should explicitely *ask* for the FQDN
c) whether, by default, the FQDN and site name should differ

First with (a): I believe this is a hard bug to fix. Either we start doing crazy things by listing the interfaces and IPs, or we try to look at ping times, or other stupid things I can think of. I just would make sure the master server is the right name, which brings us to...

(b) I don't feel we should prompt for it. It's a bit confusing to be asked the "server name" twice. We can just assume that proper admins have their FQDN set properly and just use that, couldn't we? Then people can use --aegir_host= to change it, of course. Note that we have a general problem here that it's not clear what flags you can give to the installer and how it maps to the prompts and echoed values.. Not sure how to fix that.

(c) I am not sure I see the point arguing more about this other than say that if we have proper defaults, this doesn't matter. I would default both to the FQDN. The site name is passed as an arg, so that's easy to change, and the FQDN defaults well, to the FQDN, which seems fine to me. I wouldn't always *force* a difference between the names, I would just let the admin decide.

Again, I propose to simply change the default from "$site" to "FQDN" for the ... FQDN! I was a bit hesitant in defaulting it to the site name, it was making sense for my tests here, but I'd be happy to just change that back to FQDN and get it over with.

How strongly attached are people to that silly prompt? I'd like to just keep it like that (not prompted, but overrideable with --aegir_host)..

anarcat’s picture

anarcat CreditAttribution: anarcat commented
Assigned: Unassigned » anarcat

Will resolve this today.

anarcat’s picture

anarcat CreditAttribution: anarcat commented
Status: Needs work » Closed (works as designed)

So I changed the default to be the FQDN for the FQDN, which seems to be the right thing to do here.

If you guys are really attached to prompting for the FQDN (keep in mind it's showed to the user before the install is started), reopen this issue.

  • Commit a589533 on debian, dev-migrate_aliases, prod-koumbit, dev-ssl-ip-allocation-refactor, dev-1205458-move_sites_out_of_platforms, 7.x-3.x, dev-subdir-multiserver, 6.x-2.x-backports, dev-helmo-3.x by anarcat: 
    #977324 - default the FQDN to provision_fqdn() instead of the site name

  • anarcat committed a589533 on 
    #977324 - default the FQDN to provision_fqdn() instead of the site name

  • anarcat committed a589533 on 7.x-3.x-1966886-context-to-entity 
    #977324 - default the FQDN to provision_fqdn() instead of the site name

  • anarcat committed a589533 on 6.x-2.x-1995506-profile-option 
    #977324 - default the FQDN to provision_fqdn() instead of the site name