| [11:42:15] | * Egyptian[Home] has quit (Quit: Leaving.) |
| [11:43:29] | * Egyptian[Home] has joined #aegir |
| [12:39:10] | * wolfpackmars2 has quit (Read error: Connection reset by peer) |
| [12:39:16] | * colan has joined #aegir |
| [12:39:30] | * Deciphered is now known as DecipheredAFK |
| [12:39:36] | * flashpoint9 has joined #aegir |
| [12:43:46] | * flashpoint9 has quit (Ping timeout: 244 seconds) |
| [13:02:10] | * DecipheredAFK is now known as Deciphered |
| [13:06:59] | * inteja has quit (Ping timeout: 240 seconds) |
| [13:11:58] | * Deciphered is now known as DecipheredAFK |
| [13:19:07] | * DecipheredAFK is now known as Deciphered |
| [13:25:22] | * inteja has joined #aegir |
| [14:14:52] | * colan has quit (Ping timeout: 252 seconds) |
| [14:24:30] | * moj0rising has joined #aegir |
| [14:26:17] | <moj0rising> | Hello! I am having a bit of trouble and am hoping someone might be able to get me going in the right direction. When I attempt 'drush hostmaster-install', I get errors: "Could not find the alias @hostmaster" and "Illegal string offset 'site' backend.inc:1037 [warning] |
| [14:26:22] | <moj0rising> | The command could not be executed successfully (returned: Could not find the alias @hostmaster" |
| [14:27:59] | <moj0rising> | I see in the .drush directory, that this @hostmaster item might potentially be missing from there, though I don't know of a proper way to add it. I have followed the offical Aegir documentation for installation. |
| [14:43:29] | * mstenta has quit (Ping timeout: 240 seconds) |
| [15:03:25] | * moj0rising has left #aegir () |
| [15:20:49] | * dean has quit (Ping timeout: 255 seconds) |
| [15:28:38] | * Egyptian[Home] has quit (Quit: Leaving.) |
| [15:31:16] | * colan has joined #aegir |
| [15:32:51] | * Deciphered is now known as DecipheredAFK |
| [15:44:19] | * colan has quit (Ping timeout: 248 seconds) |
| [16:32:04] | * dean has joined #aegir |
| [16:33:31] | * jerryitt has quit (Quit: Connection closed for inactivity) |
| [18:28:19] | * jerryitt has joined #aegir |
| [18:38:13] | * boshtian has joined #aegir |
| [18:59:13] | * boshtian has quit (Quit: boshtian) |
| [19:06:32] | * rominronin has joined #aegir |
| [19:23:36] | * ybabel has joined #aegir |
| [19:24:29] | * rominronin has quit (Ping timeout: 240 seconds) |
| [19:25:39] | * rominronin has joined #aegir |
| [19:26:31] | * inteja has quit (Ping timeout: 255 seconds) |
| [19:42:34] | * helmo_ is now known as helmo |
| [20:53:31] | * jerryitt has quit (Quit: Connection closed for inactivity) |
| [20:58:44] | * Einherjer has joined #aegir |
| [21:01:03] | * Einherjer has quit (K-Lined) |
| [21:05:01] | * gandhiano has joined #aegir |
| [21:11:15] | * gandhiano has quit (Ping timeout: 250 seconds) |
| [21:15:48] | * inteja has joined #aegir |
| [21:49:23] | * darthsteven has joined #aegir |
| [21:49:54] | * darthsteven has quit (Client Quit) |
| [21:56:36] | * darthsteven has joined #aegir |
| [22:18:56] | * gandhiano has joined #aegir |
| [22:39:14] | * drupol has quit (Ping timeout: 240 seconds) |
| [22:42:48] | * drupol has joined #aegir |
| [22:50:41] | * Egyptian[Home] has joined #aegir |
| [23:11:48] | * Egyptian[Home] has quit (Quit: Leaving.) |
| [23:16:34] | * inteja has quit (Ping timeout: 240 seconds) |
| [23:18:14] | * gandhiano has quit (Ping timeout: 244 seconds) |
| [23:55:28] | * mstenta has joined #aegir |
| [00:14:32] | * inteja has joined #aegir |
| [00:33:05] | * noecc has joined #aegir |
| [01:03:53] | * Einherjer has joined #aegir |
| [01:08:28] | * flashpoint9 has joined #aegir |
| [01:27:44] | * zombiebeard has joined #aegir |
| [01:51:30] | * inteja has quit (Ping timeout: 276 seconds) |
| [02:15:07] | * flashpoint9 has quit (Remote host closed the connection) |
| [02:22:23] | * colan has joined #aegir |
| [02:29:36] | * omega8cc has joined #aegir |
| [02:35:50] | * flashpoint9 has joined #aegir |
| [02:36:35] | <omega8cc> | hefring: botsnack |
| [02:36:35] | <hefring> | :) |
| [02:38:20] | * christefano has joined #aegir |
| [02:39:26] | <omega8cc> | hefring: tell bgm re: Error: Cannot redeclare — this happens because you are follwing recipe for disaster #4 at https://omega8.cc/the-best-recipes-for-disaster-139 — I have quoted mig5 there to explain why using site level codespace is a bad idea for any module which uses/depends on includes |
| [02:39:26] | <hefring> | omega8cc: I'll pass that on when bgm is around. |
| [02:45:25] | <bgm> | omega8cc: so you're saying aegir sites should never host site-specific modules? |
| [02:45:25] | <hefring> | bgm: 5 min 59 sec ago <omega8cc> tell bgm re: Error: Cannot redeclare — this happens because you are follwing recipe for disaster #4 at https://omega8.cc/the-best-recipes-for-disaster-139 — I have quoted mig5 there to explain why using site level codespace is a bad idea for any module which uses/depends on includes |
| [02:47:21] | <bgm> | I have to disagree with mig5 on that one.. |
| [02:48:28] | <omega8cc> | bgm: never by default, only code which has to remain private per site for some reason and doesn’t depend on file includes calls, otherwise Aegir will never run updates provided by these modules and instead will fail on those broken migrations, it is totally againts basic Aegir principles and workflow to have codebase in the site-level space, it just doesn’t work and can’t work |
| [02:49:09] | <omega8cc> | bgm: you can’t really disagree with facts :) |
| [02:49:10] | <bgm> | omega8cc: yes, but sometimes we don't want to support a contrib module as part of our platform, or site-specific custom code.. |
| [02:49:22] | <bgm> | that's not facts, it's bad design :) |
| [02:49:47] | <bgm> | it's "oh.. we have a bug, but anyway users shouldn't do that".. but they do, and for a reason :) |
| [02:50:41] | <bgm> | besides, I'm not sure this bug affects only sites-modules |
| [02:51:25] | <bgm> | in my case I was cloning within a same platform, but presuming it's a cache-flush issue, it affects all modules, it's just that modules in sites/all were in the same location, but on a cross-platform migrate, all modules would have been affected..? |
| [02:51:32] | * darthsteven has quit (Quit: darthsteven) |
| [02:51:34] | <bgm> | (running "truncate cache;" solves the issue) |
| [02:52:12] | <omega8cc> | bgm: it must be that way, there is no workaround, because the site space is tarballed etc so the code is never executed when you migrate the site and is never upgraded via MIgrate task, it just doesn’t make any sense in Aegir hosted sites, it is against logic, unless you are prepared for these troubles |
| [02:53:24] | <omega8cc> | bgm: it happens because system table has paths which don’t exist during the clone/migrate task, hence the error, or even php opcache has them in memory etc |
| [02:53:37] | <bgm> | weird.. I've been using aegir for many years, and only run into this now (hence suspecting a change in drupal core) |
| [02:54:01] | <bgm> | ah, maybe opcache could be another lead |
| [02:54:24] | <omega8cc> | or redis if used |
| [02:55:11] | <omega8cc> | bgm: that is why we had the on-the-fly registry-rebuild in BOA in the past |
| [02:55:12] | <bgm> | doesn't aegir deploy the site code, import the DB, then re-bootstrap as the new site? |
| [02:55:35] | <omega8cc> | but it is normally too heavy to rebuld registry a few times during singbe migrate task |
| [02:56:45] | <bgm> | or what about removing/ignoring the cache tables data, during migrate? |
| [02:56:58] | <bgm> | (cache tables are often huge and slow to import anyway) |
| [02:57:29] | <omega8cc> | it is not that simple, because files on disk and their paths in the system table will go out of sync, plus opcache, redis etc |
| [02:58:29] | <omega8cc> | the problem is not cause just by caches, but by registry which goes out of sync when paths change |
| [02:58:50] | <bgm> | i.e. {system} table? |
| [02:59:08] | <omega8cc> | and when the site dir is move around as an archive, its code just disappears during this time |
| [02:59:11] | <omega8cc> | yes |
| [02:59:17] | <bgm> | (i'm not too familiar with the drupal registry system, where it's stored, etc) |
| [02:59:53] | <bgm> | drupal is usually OK with code moving around though (surprisingly) |
| [03:00:00] | <omega8cc> | no really |
| [03:00:18] | <omega8cc> | then why registry-rebuild exists? |
| [03:00:50] | <bgm> | isn't registry-rebuild part of "clear all caches", which happens during migration? |
| [03:00:57] | <omega8cc> | no |
| [03:01:11] | <bgm> | hmm ok |
| [03:01:25] | <omega8cc> | that is the problem |
| [03:02:16] | * hestenet has joined #aegir |
| [03:04:05] | <bgm> | omega8cc: i'm curious to read the aegir code that handles the registry-rebuild, to better under the issue. do you know where it might be? |
| [03:04:12] | <omega8cc> | bgm: we have made it optional in BOA with sites/all/modules/registry-rebuild.ini — https://gist.github.com/omega8cc/a1b480818965aa2ed3f0 |
| [03:04:21] | <omega8cc> | Aegir doesn’t do that at all |
| [03:04:34] | <omega8cc> | there is an extra task which can be run manually |
| [03:04:46] | <bgm> | oh ok, cool, that's a really useful snippet. thanks! |
| [03:04:54] | <omega8cc> | and it requires registry_rebuild extension |
| [03:06:30] | <omega8cc> | np |
| [03:09:37] | <bgm> | it seems to get called by drush updatedb though? |
| [03:09:48] | <bgm> | i.e. as part of system_rebuild_module_data() |
| [03:10:08] | <bgm> | but will do more testing :) |
| [03:12:26] | <omega8cc> | updatedb — it is run too late to not fail on those includes/duplicates, and updatedb will do nothing for modules hidden in the archive moved / cloned anyway |
| [03:16:39] | <bgm> | hmm ok |
| [03:19:31] | <omega8cc> | also because modules hidden in the archive remain the same, so there is nothing for updatedb to run there, ever |
| [03:19:48] | <omega8cc> | just their paths change |
| [03:22:05] | <omega8cc> | effectively you must update such modules in-place (both their code and db updates), because they are never updated when you migrate the site between platforms |
| [03:22:30] | <bgm> | I understand the argument from the point of view of always being able to roll-back |
| [03:22:47] | <omega8cc> | it is not about rollback |
| [03:23:11] | <omega8cc> | it is about the simple fact that these modules code just can’t be executed during migration |
| [03:24:22] | <omega8cc> | so its db updates are never applied, and codebase will never change, unless you will upload it in-place |
| [03:24:52] | <omega8cc> | which is kind of against the entire idea |
| [03:25:13] | <bgm> | I don't know the migrate process well enough, but it sounds odd.. since one would expect the code to be deployed (untar backup), sql imported, then site to be bootstrapped.. |
| [03:26:15] | <bgm> | i.e. when the site is bootstrapped, i would have expected the custom code to be already deployed |
| [03:26:31] | <bgm> | so rebuilding registry once at that point would do the job |
| [03:26:43] | <bgm> | then again, drupal is drupal :) |
| [03:27:47] | <omega8cc> | drupal is bootstrapped to various stages a few times during migrate task, and there are moments (long) when the code inside the site’s level codebase just doesn’t exist (is hidden inside the tarball) |
| [03:28:56] | <omega8cc> | which may result with some fancy disasters :) |
| [03:29:13] | <bgm> | hehe |
| [03:29:41] | <bgm> | to be honest, I don't use migrate much. too many issues, but often civicrm-specific |
| [03:30:02] | <bgm> | for dev sites, I create a new site, sync code, then sync the DB |
| [03:30:24] | <omega8cc> | oh, maybe that is why you still use Aegir, or rather, you don’t really use Aegir ;) |
| [03:30:38] | <bgm> | yeah, it's my compromise :) |
| [03:31:26] | <bgm> | well, I use cloning a lot, but on a specific set of sites. for more complicated sites, i sync manually. |
| [03:31:44] | <bgm> | often I have jenkins doing a db sync during the night, take screenshots, etc |
| [03:32:38] | <bgm> | but I'm ok on blaming those methods on our "bad practices", aegir works well for us most of the time :) |
| [03:32:57] | <bgm> | (keep in mind I even worked on wordpress support) |
| [03:34:55] | <omega8cc> | every tool and workflow has its idiosyncrasy, and normally it is worth to bend yourself a bit to adjust to its weird behaviour and get the job done, at least that is the method to leverage what it offers |
| [03:35:46] | <bgm> | yep, and we do bend, but to an extent :) |
| [03:36:23] | <bgm> | and as i said, I've been using aegir for years, using this workflow (custom code in site-specific directory), but only started encountering this now. |
| [03:36:41] | <bgm> | anyway, it's very tangential, and will dig more |
| [03:36:52] | <bgm> | but thanks for the brainstorm and pointers :) |
| [03:38:06] | <omega8cc> | note that this problem is really old if mig5 explained it in 2011 :) |
| [03:42:19] | <bgm> | yep.. |
| [03:43:16] | * darthsteven has joined #aegir |
| [03:45:48] | * rominronin has quit (Remote host closed the connection) |
| [04:03:03] | * freiheit has joined #aegir |
| [04:04:37] | * freiheit has left #aegir () |
| [04:08:07] | * zz_drakythe is now known as drakythe |
| [04:12:59] | * boshtian has joined #aegir |
| [04:25:37] | * boshtian has quit (Ping timeout: 255 seconds) |
| [04:29:12] | * darthsteven has quit (Quit: darthsteven) |
| [04:30:05] | * darthsteven has joined #aegir |
| [04:46:24] | * rominronin has joined #aegir |
| [04:51:29] | * rominronin has quit (Ping timeout: 244 seconds) |
| [04:53:33] | * jerryitt has joined #aegir |
| [05:05:35] | * rominronin has joined #aegir |
| [05:36:41] | * colan has quit (Quit: colan) |
| [05:37:22] | * gusaus has joined #aegir |
| [05:41:56] | * moj0rising has joined #aegir |
| [05:46:25] | * moj0rising has quit (Ping timeout: 240 seconds) |
| [05:46:32] | * christefano has quit (Quit: christefano) |
| [05:48:21] | * moj0rising has joined #aegir |
| [05:48:34] | <moj0rising> | I have followed the official docs and searched Google, which only turned up two results but no solution. |
| [05:50:20] | <moj0rising> | I also tried creating my own hostmaster alias file, yet the script still can not seem to find it. It's been quite a challenge. If anyone can even nudge me in the right direction on this one, it would be hugely appreciated. |
| [05:51:17] | * cweagans has joined #aegir |
| [05:52:23] | <moj0rising> | Ah! Oh, wow. It worked. Ha. |
| [05:53:03] | <moj0rising> | If anyone is curious, what I did was run again, this time clearing Drush cache beforehand. |
| [05:53:48] | <moj0rising> | So creating the hostmaster alias ultimately resolved it, but cache had to be cleared in order for that to work. |
| [05:55:03] | <moj0rising> | If anyone comes back and has an idea why that file wasn't created in the first place, it would be great to know. I've been over and over the instructions and don't see that I've missed any steps (though I could have). |
| [06:02:39] | <jonpugh> | moj0rising: It's not easy to tell why an installation would be missing the hostmaster alias, but I can tell you that it gets created in the `drush hostmaster-install` command provided by provision: https://github.com/drupalprojects/provision/blob/7.x-3.x/install.hostmas... |
| [06:04:18] | * cweagans has quit (Quit: Leaving) |
| [06:05:55] | <jonpugh> | it should be automatic. Best to start with a fresh server, ubuntu 14 LTS or ... Debian 7 i guess? not sure which is more supported |
| [06:06:13] | <jonpugh> | having anything in your server already tends to cause unexpected issues |
| [06:07:12] | <moj0rising> | Very strange. SO it should have been created for me already. |
| [06:08:28] | <moj0rising> | Lame about the Having anything in your server already causing unexpected issues. I am building this in a very controlled environment and was hoping to not have to ask them to provision a new machine for me (installing aegir 3 on a machine that had aegir 2. I did archive everything aegir 2 that I could find). |
| [06:08:36] | <moj0rising> | We |
| [06:08:45] | <jonpugh> | it's not that it can't be done |
| [06:08:55] | <jonpugh> | it's just that you will experience strange things, which is what is happening to you :) |
| [06:09:06] | <jonpugh> | usually you can work it out. |
| [06:09:21] | <jonpugh> | i'm just saying, a clean server install from scratch works, 100% of the time. |
| [06:09:22] | <moj0rising> | oops. We're running CentOS 7, actually I beleive it's Red Hat (same thing of course). I don't believe I can run a debian variant here. |
| [06:09:34] | <jonpugh> | that's fine too |
| [06:09:41] | <moj0rising> | Cool. |
| [06:09:41] | <jonpugh> | you just have to maintain it yourself to some degree |
| [06:09:50] | <jonpugh> | i'm not sure if anyone got around to finalizing an RPM... |
| [06:09:56] | <jonpugh> | ergonlogic: do you know? |
| [06:10:03] | <moj0rising> | That's not too bad, as long as I can work out what the heck is wrong with it. :) |
| [06:10:22] | <jonpugh> | Sometimes it helps to fire up a VM with a clean install to compare it |
| [06:11:10] | <moj0rising> | Yeah. I was just about to do that. I will go ahead and do it anyway. I can fire up VMs to my heart's content in our own environment, just not on this client's network. |
| [06:11:30] | <moj0rising> | That will give me a good base for troubleshooting in case something goes wrong in the future. |
| [06:11:37] | <jonpugh> | you might want to explore setting up your client servers as "remote" if possible. |
| [06:12:01] | <moj0rising> | Sorry. What does that mean. :) |
| [06:12:16] | <jonpugh> | You can setup a "remote server" and have one aegir server deploy to separate servers via SSH |
| [06:12:28] | <jonpugh> | meaning you can have your hostmaster server separate |
| [06:12:40] | <jonpugh> | it's a lot more moving parts on the hostmaster server. |
| [06:12:53] | <jonpugh> | remotes only need apache/mysql/php and ssh access |
| [06:13:09] | <jonpugh> | here: https://aegir.readthedocs.org/en/latest/usage/advanced/remote-servers/ |
| [06:13:15] | <moj0rising> | Ah. Then run the hostmaster from our network? |
| [06:13:25] | <jonpugh> | yeah, from anywhere |
| [06:13:31] | <jonpugh> | as long as it has SSH access to the target |
| [06:13:34] | <jonpugh> | it uses RSYNC |
| [06:13:49] | * noecc has left #aegir ("pax") |
| [06:13:49] | <jonpugh> | and root database access on the target |
| [06:13:52] | <moj0rising> | Thanks. That's a great feature, though they most likely would not approve it in this case. :/ |
| [06:14:02] | <moj0rising> | ..though it it great to know about as an option. |
| [06:14:28] | <jonpugh> | happy to help |
| [06:15:11] | <moj0rising> | Thanks so much. You have been a huge help! :) |
| [06:36:21] | * colan has joined #aegir |
| [06:55:07] | * flashpoint9 has quit (Remote host closed the connection) |
| [07:20:33] | * spidey has quit (*.net *.split) |
| [07:20:34] | * azend|vps has quit (*.net *.split) |
| [07:20:42] | * nulp has quit (*.net *.split) |
| [07:20:51] | * spidey has joined #aegir |
| [07:20:59] | * nulp has joined #aegir |
| [07:24:08] | * azend|vps has joined #aegir |
| [07:26:01] | * moj0rising has quit (Ping timeout: 240 seconds) |
| [07:28:14] | * moj0rising has joined #aegir |
| [07:41:45] | * gandhiano has joined #aegir |
| [07:46:01] | * omega8cc has quit (Quit: Cheers! It's Time for Offline Reality) |
| [07:55:41] | * moj0rising has left #aegir () |
| [07:56:57] | * flashpoint9 has joined #aegir |
| [08:21:46] | <ergonlogic> | jonpugh: no RPMs yet, AFAIK |
| [08:43:59] | * inteja has joined #aegir |
| [08:55:50] | * ybabel has quit (Quit: ybabel) |
| [09:50:46] | * Egyptian[Home] has joined #aegir |
| [09:54:49] | * Egyptian[Home]1 has joined #aegir |
| [09:54:56] | * Egyptian[Home] has quit (Client Quit) |
| [10:00:29] | * gandhiano has quit (Ping timeout: 240 seconds) |
| [10:02:41] | * zombiebeard has quit (Quit: zombiebeard) |
| [10:10:18] | * colan has quit (Quit: colan) |
| [10:47:54] | * flashpoint9 has quit (Remote host closed the connection) |
