I have the need to run a bunch of versions of sites, and our URL scheme is pretty long.
We use a bunch of drush tools that refer to these sites by alias, not just the Aegir UI.

We have rapidly found that any decent project starts chopping off the site URL arbitrarily, and I can't imagine a good reason for this to be a neccessary restricting in the code. It makes it hard to keep our commandline and documentation consistent if we can't have a 1:1 match between the site hostname and the site-alias

Example (sligthly exaggerated) URL:
dev.platformversion.projectname.longclientname.hostserver.ourlongcompanyname.co.nz

Our companyname is long 'sparksinteractive.co.nz'
and the hostserver is in there to take advantage of wildcardDNS.
Often clientname and projectname are the same, but not always.
As Aegir encourages each release of a build to be a new platform, we sometimes have to insert the platformversion in there.

Objections to the naming style that has led us here aside (I also encountered this when trying to use temporary AWS URLs),
that is the workflow/schema I have to *be able to* support.
But hosting.module forces a chop at
dev.platformversion.projectname.longclientname.hos
just because the database schema was being stingy with bytes.

mysql> describe hosting_context;
+-------+------------------+------+-----+---------+-------+
| Field | Type             | Null | Key | Default | Extra |
+-------+------------------+------+-----+---------+-------+
| nid   | int(10) unsigned | NO   | PRI | 0       |       |
| name  | varchar(50)      | NO   | UNI | NULL    |       |
+-------+------------------+------+-----+---------+-------+

Unless there is a genuine reason why Aegir's head would explode when presented with a longer URL, I propose a schema update 

 ALTER TABLE hosting_context MODIFY name VARCHAR(128);

Sorry, I can't tell the 'hosting' version from inspecting the site report or the code, it's the one with hostmaster profile 6.x-1.9

I've tried this on a test hostmaster, and seems to work. Even if this suggestion won't be accepted here, can anyone warn my why this may not be a good idea for me to run on my production server?

CommentFileSizeAuthor
#12 hostmaster.code_.1971348-12.patch3.15 KBchertzog
#11 hostmaster.code_.1971348-11.patch3.13 KBhelmo
#7 alias.patch2.07 KBchertzog
#5 alias.patch2.07 KBchertzog
#4 alias-length.patch3.18 KBchertzog
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
CreditAttribution: ergonlogic commented

Interesting... Digging into this bit, that line in hosting_schema() appears to have been introduced in http://drupalcode.org/project/hostmaster.git/commit/28a7ac8955a25358159a.... The commit message refers to #723288: Introduce the concept of 'shortnames' for all major entities., which doesn't justify a length of 50 characters, that I can see anyway.

So, since this value appears to be arbitrary, I propose implementing @dman's suggestion. If there aren't any objections in the next few days, I'll go ahead and make the requisite modifications.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented
Project: Hosting » Hostmaster (Aegir)
Version: 6.x-0.3 » 6.x-2.x-dev
Category: task » bug

This is a bug, because we shouldn't limit the site name length on the SQL level - it causes those weird This task is not valid errors when the drush alias name gets truncated because of this silent limitation.

It is also much less than legitimate max domain name length, which is 253.

But even with some (if any) limit enforced in the schema, we should limit this on the code level first, to avoid silent name truncating on the SQL level.

Moving this to the correct queue.

anarcat’s picture

anarcat CreditAttribution: anarcat commented

just changing the database is not enough - we need to validate the heck out of this thing.

i agree with 253, even though I think it's rather silly.

chertzog’s picture

chertzog
he/him
Primary language English
Location Harrisburg, PA, USA
CreditAttribution: chertzog commented
Status: Active » Needs review
FileSize
alias-length.patch3.18 KB

How about this? Im not sure if checks need to be placed anywhere else, but here is a start.

chertzog’s picture

chertzog
he/him
Primary language English
Location Harrisburg, PA, USA
CreditAttribution: chertzog commented
FileSize
alias.patch2.07 KB

better patch with out the whitespace stuff....

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented
Status: Needs review » Needs work

While 253 is already absurdly long, we need to lower it to 235, or someone will hit the 256 filename max limit, because the actual filename of the drush alias has the .alias.drushrc.php extension added.

chertzog’s picture

chertzog
he/him
Primary language English
Location Harrisburg, PA, USA
CreditAttribution: chertzog commented
Status: Needs work » Needs review
FileSize
alias.patch2.07 KB

Updated.

dman’s picture

dman CreditAttribution: dman commented

I see no reason why this shouldn't go in pretty easily.
:-)

helmo’s picture

helmo CreditAttribution: helmo commented
Status: Needs review » Needs work 
@@ -60,11 +60,29 @@ function hosting_alias_help($path, $arg) {
+    if ($length > 253) {
+      $long = $length - 253;

This specifies 253 instead of 235

@@ -25,7 +25,7 @@ function hosting_schema() {
-        'length' => 50,
+        'length' => 235,

We would need an update hook to change this in existing installations

anarcat’s picture

anarcat CreditAttribution: anarcat commented

please make that magic number a define() too so that it's not so magic.

helmo’s picture

helmo CreditAttribution: helmo commented
Status: Needs work » Needs review
FileSize
hostmaster.code_.1971348-11.patch3.13 KB

Added HOSTING_MAX_ALIAS_LENGTH ... can we use that constant in the hook_schema and hook_update_N?

chertzog’s picture

chertzog
he/him
Primary language English
Location Harrisburg, PA, USA
CreditAttribution: chertzog commented
FileSize
hostmaster.code_.1971348-12.patch3.15 KB

@helmo according to the docs of hook_schema (https://api.drupal.org/api/drupal/modules%21system%21system.api.php/func...), you can rely on the .module to be available during install, just not uninstall.

looks good to me.

Attached patch updated the hook_update number.

helmo’s picture

helmo CreditAttribution: helmo commented

The D7 docs specify:

Not all module functions are available from within a hook_update_N() function. In order to call a function from your mymodule.module or an include file, you need to explicitly load that file first.

But for D6 there is no such mention...

anarcat’s picture

anarcat CreditAttribution: anarcat commented
Status: Needs review » Needs work

hum, so then we need to include that file.

clemens.tolboom’s picture

clemens.tolboom
Primary language Dutch
Location Groningen, 🇳🇱/🇪🇺
CreditAttribution: clemens.tolboom commented 
  1. +++ b/hosting.install
@@ -509,3 +510,19 @@ function hosting_update_6206() {
+        'length' => HOSTING_MAX_ALIAS_LENGTH,

    I would not use a constant in a hook_update_N as the constant can change in the future. Then there is no reference anymore to the changed except the constant itself. Hard to debug.

    One could use it for hook_schema 

  2. +++ b/hosting.install
@@ -509,3 +510,19 @@ function hosting_update_6206() {
\ No newline at end of file

    No eof

My 2cnts

helmo’s picture

helmo CreditAttribution: helmo commented
Status: Needs work » Fixed

thanks @clemens.tolboom

I've updated the patch and committed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

(not verified) CreditAttribution: commented
Issue summary: View changes

Updated issue summary.