| [11:06:03] | * xk has joined #aegir |
| [11:08:34] | * Haza` is now known as Haza`Aw |
| [11:10:05] | * mikejoconnor has joined #aegir |
| [11:11:22] | <xk> | hmm |
| [11:12:17] | <xk> | with multiserver management, if you have a site on a remote (spoke) server... what happens if you do a verify? does it copy the data from hub (master) to spoke (remote)? |
| [11:13:03] | <mig5> | yes |
| [11:14:32] | <xk> | well... what happens if you update/change the site in production, where the site is hosted on the spoke (remote) server? |
| [11:14:57] | <mig5> | you shoot yourself in the foot. |
| [11:15:07] | <mig5> | depends what you mean by update/change |
| [11:15:17] | <xk> | well, add new content (files/images) |
| [11:15:27] | <mig5> | in beta2, it blows it away, which is a bug and has been fixed |
| [11:15:35] | <mig5> | re: the files dir |
| [11:15:42] | <mig5> | (or anything else, really) |
| [11:16:04] | <mig5> | that is the only case where you should be changing the live site directly. adding other modules etc directly in production is of course ridiculous and no-one in their right mind does things like that on the fly :) |
| [11:16:11] | <xk> | ok |
| [11:16:20] | <mig5> | but yes, uploading files etc should be fine, if you are experiencing that bug, there's a patch for it |
| [11:16:27] | <mig5> | http://drupal.org/node/976300 |
| [11:16:40] | * Irishgringo has joined #aegir |
| [11:16:53] | <xk> | so there's finally a solution to my bug report? :) |
| [11:17:00] | <mig5> | yep |
| [11:17:08] | <mig5> | #34 |
| [11:18:02] | <mig5> | at least it resolves the data loss issue. your bug touches on about 3 or 4 different issues and i lost track of what was bug and what was not. |
| [11:18:18] | <mig5> | i at least fixed what i could reproduce. |
| [11:18:21] | <xk> | heh |
| [11:18:25] | * fastdesign has joined #aegir |
| [11:26:37] | <xk> | I created a file manually on the remote server, did a verify, nothing was sync'd. |
| [11:26:47] | <xk> | atleast the site didn't get wiped :) |
| [11:27:41] | <mig5> | nothing was synced because nothing was different on the master server |
| [11:27:45] | <mig5> | it's an incremental rsync |
| [11:28:15] | <mig5> | it doesn't sync stuff *back* from the remote server to the master, except in the case of taking a backup (which is also implied for tasks like migrate, clone etc) |
| [11:28:22] | <xk> | ah |
| [11:28:53] | <xk> | ok, i can see backup did a sync back to master. |
| [11:31:36] | * AquaticDisorder_ has joined #aegir |
| [11:34:02] | * AquaticDisorder has quit (Ping timeout: 240 seconds) |
| [11:39:10] | * catatonicrelapse has quit (Ping timeout: 240 seconds) |
| [11:43:02] | * mikejoconnor_ has joined #aegir |
| [11:46:02] | * mikejoconnor has quit (Ping timeout: 240 seconds) |
| [11:46:38] | <xk> | hmmm |
| [11:46:46] | <xk> | it still doesn't fix the migrate issue |
| [11:47:06] | <xk> | migrate from master to remote server, the website is 100% deleted from master. |
| [11:47:20] | * mikejoconnor_ has quit (Ping timeout: 255 seconds) |
| [11:47:22] | <mig5> | i see |
| [11:47:37] | <mig5> | so it doesn't recognise itself as the 'master' pristine copy |
| [11:47:43] | <mig5> | and completes a standard migration |
| [11:47:56] | <mig5> | let's open a new ticket about that |
| [11:47:58] | <mig5> | that can even be the title |
| [11:48:00] | <mig5> | 11:45 < xk> migrate from master to remote server, the website is 100% deleted from master. |
| [11:48:04] | <xk> | ok |
| [11:48:46] | <mig5> | we probably just need a simple check in there that goes 'if $server != @server_master'; (the delete hook) |
| [11:48:50] | <mig5> | (pseudocode) |
| [11:49:08] | <mig5> | i'll try and reproduce that too |
| [11:49:25] | <mig5> | as i haven't noticed it before, and i've migrated sites from the master server to remote before |
| [11:50:07] | <xk> | so what I basically did was this: create new site, manually copy site from another server, verify, migrate, *site is 100% deleted from master* |
| [11:50:26] | <xk> | I'll see if it happens without the manual copy. |
| [11:50:29] | <mig5> | 'manually copy site from another server' |
| [11:50:31] | <mig5> | i don't follow that |
| [11:50:46] | <xk> | well, since I can't do a restore, I have to copy over an existing website. |
| [11:50:50] | <mig5> | is that a different site to the 'create new site' |
| [11:50:51] | <mig5> | right |
| [11:50:55] | <mig5> | (you can import sites) |
| [11:50:58] | <mig5> | but anyway |
| [11:51:04] | <xk> | yeah? |
| [11:51:09] | <mig5> | yep |
| [11:51:10] | <xk> | I |
| [11:51:13] | <xk> | I'll have to try that |
| [11:51:13] | * jhedstrom has quit (Read error: Operation timed out) |
| [11:51:22] | <mig5> | http://community.aegirproject.org/node/21 |
| [11:52:01] | <xk> | just do a verify platform and it adds the site automatically? |
| [11:52:09] | <mig5> | yep |
| [11:52:32] | <mig5> | so long as it isn't sites/default (i.e come from a non-multisite setup. you have to do some tweaks there if so, but the docs there cover those cases) |
| [11:52:40] | * jhedstrom has joined #aegir |
| [11:54:49] | <mig5> | so we just need to check what d()->server is when we start the migration, and if it was server_master, don't run the post delete hook |
| [11:54:53] | <mig5> | i'll test it out a bit later |
| [11:55:16] | <mig5> | hmm, *although* |
| [11:55:29] | <mig5> | the site could feasibly be getting migrated between platforms just locally on that master server |
| [11:55:36] | <mig5> | in which case it *should* delete the old one |
| [11:55:38] | <mig5> | so, gets tricky |
| [11:56:07] | <mig5> | have to compare the server of the target platform |
| [11:56:24] | <xk> | I'll do some testing. |
| [11:58:18] | <mig5> | if (d()->server == '@server_master' && d($platform->server) !== '@server_master') { drush_set_option('migrating_from_master', TRUE); } |
| [11:58:21] | <mig5> | or something :) |
| [11:58:30] | <mig5> | in drush_provision_drupal_pre_provision_migrate() |
| [11:58:37] | <mig5> | (these are mainly notes for myself for later) |
| [11:58:59] | <xk> | I wonder what happens for remote->master migrate. oh... that's not possible since it's hub->spoke model. |
| [11:59:22] | <mig5> | in theory you should be able to migrate it back to the master actually |
| [11:59:34] | <mig5> | just can't migrate it between multiple masters :) |
| [11:59:43] | <mig5> | or, rather, can't really have multiple masters (because it's a spoke model) |
| [12:00:22] | <mig5> | so it ought to be ok because it would go to a different platform ( a local platform on @server_master) |
| [12:00:37] | <xk> | ah ok |
| [12:00:40] | <mig5> | but yes, in that situation it will have to know to clean up the copy of the site in the platform that was considered remote |
| [12:00:48] | <mig5> | it probably does that already |
| [12:00:53] | * unconed has joined #aegir |
| [12:00:56] | <mig5> | might test that too |
| [12:01:20] | <unconed> | mig5: had some more issues today that show the current context behaviour is broken... |
| [12:01:35] | <mig5> | hehe, i believe you :) |
| [12:01:41] | <mig5> | i haven't had a chance to really look at your original issue yet |
| [12:01:55] | <mig5> | adrian suspects it's my fault :) |
| [12:01:58] | <unconed> | yeah, i just wasn't sure yesterday, now I am ;) |
| [12:02:02] | <unconed> | well, the problem is rather simple |
| [12:02:07] | <mig5> | since a master server can be both a 'localhost' and a fqdn |
| [12:02:57] | <unconed> | Whenever you call d(), it augments the loaded context with options from the command line... as far as I can tell, this behavior only exists to create new contexts through provision-save, yet, it is applied to every single context, no matter what. |
| [12:03:57] | <mig5> | i see - are we sure that that isn't the same mechanism used when arguments are passed from the frontend (via hosting-task) to the backend through the json? |
| [12:04:01] | <mig5> | (I don't actually know) |
| [12:04:09] | <unconed> | Yes |
| [12:04:13] | <mig5> | ok |
| [12:05:13] | <mig5> | so the stdin doesn't replace but sort of adds/merges with the existing context and you have your infinite loop? |
| [12:05:17] | <unconed> | yeah |
| [12:05:22] | <mig5> | what fun |
| [12:05:28] | <ryanarmstrong> | mig5: quick question. I know that when it comes from updating a platform from one Drupal version to another it's best to make a new platform and then migrate the sites from the old platform to the new one, but what about included modules on a platform? So if I have a platform that is D7, plus say views, token, and pathauto, and I want to update the views module to the latest version, would you recommend making a whole ne |
| [12:05:32] | <unconed> | consider you have @server_cluster, with @server_child as its child |
| [12:05:39] | <unconed> | the command line says @server_cluster has @server_child as its child, so it loads that |
| [12:05:47] | <unconed> | but then the command line says @server_child has @server_child as its child, and it recurses |
| [12:05:50] | * jhedstrom has quit (Ping timeout: 240 seconds) |
| [12:06:16] | <mig5> | ergh |
| [12:06:25] | <mig5> | i wonder if cluster is the only case where this really ever happens |
| [12:06:30] | <unconed> | nope |
| [12:06:36] | <unconed> | it actually happens all the time |
| [12:06:46] | <unconed> | during provision-save, d(@self) loads d(@server_master) |
| [12:06:59] | <unconed> | and @server_master will temporarily have the same options set as @self (the alias to be saved) |
| [12:07:21] | <unconed> | however, since usually the services match between @server_master and @server_*, this usually goes undetected |
| [12:10:05] | <mig5> | yes it sounds all sorts of broken, still struggling to get my head around the context stuff (always have, since it was written by others) |
| [12:10:11] | <xk> | mig5: hmmm... import not working. it expects the db user to exist. |
| [12:10:12] | * AquaticDisorder_ has quit (Read error: Connection reset by peer) |
| [12:10:22] | <unconed> | mig5: i had never looked at this before yesterday either |
| [12:10:31] | <mig5> | yeah but you're way ahead of me already :) |
| [12:10:37] | <mig5> | have you ideas on how to fix it? |
| [12:10:44] | <unconed> | yeah, there are two solutions |
| [12:11:02] | <unconed> | one is to explicitly grab the name of the intended @alias from the command-line, and only weave in options from the command line when loading that alias |
| [12:11:19] | <unconed> | the other is to remove the automatic weaving altogether, and just make it the responsibility of provision-save |
| [12:12:32] | <mig5> | the latter sounds like less of a hack |
| [12:12:44] | <unconed> | yeah |
| [12:12:44] | <mig5> | so long as that's the only case where we'll ever want to do it (provision-save) |
| [12:12:48] | <unconed> | i'm just unsure that that is the only case |
| [12:12:58] | * jlittlew has joined #aegir |
| [12:13:02] | <mig5> | yeah.. |
| [12:13:17] | <mig5> | wonder if i can get a hold of drumm |
| [12:13:26] | <mig5> | who i think wrote much of the getter/setter stuff here with adrian |
| [12:13:54] | <mig5> | (chapter three wrote the cluster stuff and drumm was involved with that) |
| [12:14:03] | <mig5> | and so multiserver came about like that |
| [12:14:07] | <unconed> | ah k |
| [12:14:15] | <mig5> | and multiserver resulted in contexts :) |
| [12:14:22] | <unconed> | well i'm kind of surprised since afaict, clusters are broken right now |
| [12:14:36] | <mig5> | hehe, yeah i was afraid of that.. |
| [12:14:47] | <mig5> | it WorksForThem, somehow.. i've never even tried it :s |
| [12:15:01] | <mig5> | and i can't get them to write docs for me either |
| [12:15:07] | <unconed> | i don't see how you could successfully verify / provision-save a cluster with servers in it due to this bug |
| [12:15:11] | <mig5> | josh_k: ping :) |
| [12:15:29] | <unconed> | maybe they just manually wrote drushrc files |
| [12:15:38] | <unconed> | and override hostmaster's status |
| [12:16:04] | <josh_k> | me? |
| [12:16:18] | <mig5> | josh_k: heya |
| [12:16:24] | <josh_k> | oh yeah cluster stuff |
| [12:16:33] | * mikejoconnor has joined #aegir |
| [12:16:39] | <mig5> | so unconed has identified a bug in our provision/context stuff that probably prevents it being usable |
| [12:16:50] | <mig5> | wondering how you get around it, or if you have come across it |
| [12:17:18] | <unconed> | josh_k: the symptom is that calling provision-save with servers in your cluster will cause an infinite recursion |
| [12:17:35] | <unconed> | the cause is context handling |
| [12:20:45] | * EclipseGc has quit (Quit: EclipseGc) |
| [12:21:31] | * EclipseGc has joined #aegir |
| [12:21:45] | * jhedstrom has joined #aegir |
| [12:22:19] | <mig5> | xk: yeah you have to get the db, user, and your settings.php all in order first for the import to work |
| [12:22:32] | <mig5> | it will parse the settings.php and then make it like other typical aegir-managed sites |
| [12:23:41] | <mig5> | or you can use provision-save; provision-deploy from the cli but it requires the soon-to-be-imported site to kind of be 'aegir format', i.e already have a drushrc.php with the creds, the database be database.sql in the site dir inside the tarball, etc.. more effort that way |
| [12:23:45] | <xk> | easier for me to create site then manually copy the site over. |
| [12:23:47] | <josh_k> | unconed: it's possible something changed in context since we deployed |
| [12:23:58] | * AquaticDisorder has joined #aegir |
| [12:24:02] | <josh_k> | which was initially back in September |
| [12:24:08] | <unconed> | josh_k: no upgrades since then?? |
| [12:24:10] | <josh_k> | is there an issue for this? |
| [12:24:35] | <josh_k> | unconed: when deploying alpha code, the upgrades go slow and we don't make them all |
| [12:24:49] | <josh_k> | I'm pretty sure it's also patched (I have not been personally managing the installation) |
| [12:24:54] | <josh_k> | howver, 100% certain it works |
| [12:25:07] | * q0rban|afk is now known as q0rban |
| [12:25:23] | <josh_k> | unconed: if you open an issue I can bring it to the attention of the folks who do maintain the system though |
| [12:25:24] | * jhedstrom has quit (Read error: Connection reset by peer) |
| [12:25:34] | <josh_k> | (meeting w/them tomorrow in fact) |
| [12:25:42] | <unconed> | josh_k: i wrote a post on the community site last night, but took me until now to confirm what i thought |
| [12:26:40] | <josh_k> | url? |
| [12:26:50] | <unconed> | http://community.aegirproject.org/node/267 |
| [12:26:59] | * EclipseGc has quit (Quit: EclipseGc) |
| [12:27:08] | <unconed> | the fix as described in there doesn't work though, as it applies to more than just @server_master |
| [12:27:50] | <josh_k> | is server_master part of your cluster? |
| [12:27:58] | <unconed> | i tried either |
| [12:28:14] | <unconed> | all that matters is that you have a server in your cluster |
| [12:28:22] | <unconed> | but if said server is @server_master, it dies a bit earlier |
| [12:28:35] | <unconed> | because d() explicitly recurses to it |
| [12:29:30] | <josh_k> | unconed: what version of drush are you on? |
| [12:30:09] | <unconed> | 3.3 |
| [12:30:14] | <unconed> | the offending code is in provision though |
| [12:31:22] | <josh_k> | well, I can certainly bring it to the attention of the devs who are managing the live instance |
| [12:31:34] | <josh_k> | but I haven't worked on this actively in some months |
| [12:31:49] | <josh_k> | but it seems like something worth fixing in beta for sure! :) |
| [12:31:58] | <josh_k> | this is not a bug we encountered heretofore |
| [12:32:16] | <unconed> | i haven't dug into when this behaviour was added/changed |
| [12:32:35] | <unconed> | was hoping someone here would know, but it seems nobody really does |
| [12:32:56] | <josh_k> | I don't think it's very widely used |
| [12:34:20] | * obrienmd has quit (Quit: Leaving.) |
| [12:34:22] | <josh_k> | however, it's probably not extremely hard to fix |
| [12:34:44] | <unconed> | yeah i outlined two solutions above |
| [12:34:45] | <josh_k> | I think this is probably the result of updates in provision that were made without much testing of cluster |
| [12:34:58] | * AquaticDisorder has quit (Remote host closed the connection) |
| [12:40:42] | * ryanarmstrong has quit (Quit: Leaving.) |
| [12:41:05] | <unconed> | unfortunately, the better fix is to make d(...)->options mutable |
| [12:41:17] | <unconed> | whereas now, d(...)->options is a magic variable read directly from drushrc + stdin + options |
| [12:44:31] | <mig5> | the stdin thing in the __get has been present as long as adrian seemed to have committed that code |
| [12:44:41] | <mig5> | i.e it was in the dev-services branch where all this happened |
| [12:44:57] | <mig5> | (re: when the behaviour was added) |
| [12:45:19] | <mig5> | so that's a surprise |
| [12:45:29] | <mig5> | unconed, dose one of your cluter children happen to be @server_master |
| [12:45:38] | <mig5> | does* |
| [12:45:42] | <unconed> | i tried it with and without, doesn't matter |
| [12:45:46] | <mig5> | ok |
| [12:45:57] | * jhedstrom has joined #aegir |
| [12:50:43] | <xk> | _weird_ |
| [12:50:56] | <xk> | even a MASTER->MASTER migrate deletes the site. |
| [12:51:07] | <xk> | just changing the platform. |
| [12:51:14] | <mig5> | well that is normal... |
| [12:51:27] | <mig5> | if you are moving the site between platforms on the local server, it should clean up where the old one was |
| [12:51:36] | <xk> | sorry. my bad |
| [12:51:40] | <xk> | I was looking at the wrong platform dir :) |
| [12:51:45] | <mig5> | hehe |
| [12:51:56] | <xk> | I'm doing 4 test cases. |
| [12:52:12] | <xk> | master->remote, remote->master, master->master, remote->remote. |
| [12:52:18] | <mig5> | ok |
| [12:52:19] | <xk> | first two test different web servers |
| [12:52:26] | <xk> | second two test different platforms, same web server. |
| [12:52:46] | <mig5> | so i think only the first one is where it shouldn't delete the site if it previously existed only on master. |
| [12:52:58] | <xk> | well, REMOTE->MASTER deletes on both! |
| [12:53:05] | <mig5> | ok, interesting |
| [12:53:19] | <mig5> | i have no idea why it worked for me, i did it yesterday :) |
| [12:55:41] | <mig5> | it even deleted it on the new platform on master? |
| [12:55:48] | <mig5> | or just removed it from the two copies of platform that were considered 'remote' |
| [12:55:52] | <mig5> | (which is correct) |
| [12:56:01] | <xk> | for remote->master? |
| [12:56:05] | <mig5> | yeah |
| [12:56:14] | <xk> | it deleted from the remote server and master server. |
| [12:56:15] | <mig5> | so you had to have set a new target platform (a platform only on the master server) |
| [12:56:18] | <mig5> | right |
| [12:56:28] | * recidive has quit (Quit: zzz) |
| [12:56:29] | <mig5> | but on the new target platform or on the two copies of what was considered remote? |
| [12:56:41] | <mig5> | or all of the above |
| [12:56:44] | <xk> | there was no two copies. |
| [12:56:46] | <xk> | on the same server |
| [12:56:49] | <xk> | because it was the same name. |
| [12:56:54] | <mig5> | but you said remote -> master |
| [12:57:03] | <xk> | 1 copy on each server |
| [12:57:11] | <mig5> | master would have had a platform called 'foo' that is in fact for the remote server |
| [12:57:14] | <mig5> | right |
| [12:57:33] | <mig5> | but i don't think you can, or should not be able to, migrate *back* to the platform on the master server that is defined as existing on the remote server ( but is managed by the master server) |
| [12:57:40] | <mig5> | it ought to have to be a new target platform on the master server |
| [12:57:47] | <mig5> | that has not been defined as on remote web server $bar |
| [12:57:59] | <mig5> | if we are allowing that, then *that* is a bug (it should not be a valid platform) |
| [12:58:01] | <xk> | well... it should be possible. I dont see why it cannot be |
| [12:58:09] | <mig5> | becuase it's attached to a remote server context |
| [12:58:18] | <mig5> | it just happens to also exist on master and be synced out per the spoke model |
| [12:58:33] | <mig5> | you can't migrate a *platform* to the server_master context |
| [12:59:00] | <mig5> | so, if you did a remote -> master but set the platform as the same, you are in fact doing a rename only on the remote side |
| [12:59:22] | <mig5> | but the current platform should not be a valid target unless you are changing the name of the site, so i don't even follow how you submitted the migrate form |
| [12:59:44] | <xk> | well... it gave me the option to do it :) |
| [12:59:48] | <mig5> | did you add the 'local' copy of the remote platfortm as a new platform or something (that should have also failed) |
| [12:59:52] | <mig5> | right |
| [13:00:11] | <mig5> | i'll do some testing tomorrow |
| [13:00:26] | <mig5> | but to me that sounds remote->remote, not remote->master, since the platform you chose is considered the 'remote' platform. |
| [13:00:49] | <xk> | hmm |
| [13:01:23] | <mig5> | you may not have done that but it's hard to imagine what options you chose, maybe screenshot the migrate form for the remote->master migrate if there's time |
| [13:01:28] | <mig5> | so i can see what you were doing |
| [13:01:48] | <xk> | it's a new platform on master. |
| [13:01:55] | <mig5> | ah, right |
| [13:01:56] | <xk> | it's not hostmaster (if a site can be even added to it) |
| [13:01:59] | <mig5> | so |
| [13:02:05] | <mig5> | what i want to know is |
| [13:02:15] | <mig5> | did it delete the site on the *new* platform on master, after it migrated to it |
| [13:02:29] | <mig5> | or did it leave that one in place, and just delete the site from the *old* platform (both the local copy of it and the remote one) |
| [13:02:40] | <mig5> | which would be the correct thing to do |
| [13:03:20] | <xk> | but why delete two? |
| [13:04:07] | <mig5> | because the site is no longer considered on that old platform |
| [13:04:19] | <xk> | ah |
| [13:04:20] | <mig5> | and that old platform, because it was a remote, existed on the master server (hub) and on the remote server (spoke) |
| [13:04:33] | <mig5> | now it should only exist once, on the new platform on the master server |
| [13:06:52] | <xk> | ok, im going to test REMOTE->REMOTE migrate |
| [13:07:52] | * mikeholly has joined #aegir |
| [13:08:03] | <xk> | not sure if it's worthwhile to test if the hostname changes. |
| [13:08:16] | <xk> | I'll do one or two tests. |
| [13:08:28] | <mig5> | cool |
| [13:08:40] | * mikeholly isn't running iTunes currently. |
| [13:08:49] | <mig5> | great, thanks |
| [13:08:57] | <mig5> | that's a relief |
| [13:09:15] | <xk> | yeah, it works. remote->remote migrate. |
| [13:10:48] | <xk> | I also noticed another thing |
| [13:10:58] | * recidive has joined #aegir |
| [13:11:08] | <xk> | the DB is recreated, even though the DB server is the same, and the website hostname is the same. |
| [13:11:25] | <xk> | so if the migrate fails, boom, you lose the DB stuff. |
| [13:11:30] | <mig5> | yep that happens even on master->master |
| [13:11:36] | <mig5> | well, yeah but it takes a backup first |
| [13:11:39] | <xk> | maybe that's a good thing. less cruft lying around |
| [13:12:03] | * levi501d has left #aegir () |
| [13:12:10] | <mig5> | as a rule we create a new db each time because provision-delpoy, which runs underneath of migrate, takes a tarball as an argumetn and unpacks the site then imports a new db |
| [13:12:43] | <mig5> | only if the migrate is failed, is the old database meant to be removed |
| [13:12:50] | <xk> | ok, remote->remote migrate, different hostname. 100% good. |
| [13:12:51] | <anarcat> | i wonder if we shouldn't just "delete" and "disable" instead of silently backup up the site too during those steps |
| [13:12:53] | <mig5> | so it's meant to be if the migrate fails, it could conceivably roll back |
| [13:13:00] | * josh_k has quit (Ping timeout: 272 seconds) |
| [13:13:11] | <anarcat> | but i'm not really here |
| [13:13:18] | <mig5> | hehe |
| [13:13:34] | <xk> | now the final test. remote->master, different hostname :) |
| [13:13:59] | <mig5> | isn't the hostname always different between server? |
| [13:14:08] | <xk> | I mean hostname of the website |
| [13:14:11] | <mig5> | ahh |
| [13:14:45] | <xk> | AMAZING |
| [13:14:46] | <xk> | it worked |
| [13:14:54] | <mig5> | ;) |
| [13:14:58] | <xk> | remote->master, different hostname == works. |
| [13:15:32] | <mig5> | so now what i want to know is |
| [13:15:52] | <mig5> | the one issue we think we have, is that when you migrate a site on server_master to a remote server |
| [13:16:03] | <mig5> | it deletes the copy on server_msater when it should in fact be remotely managing it |
| [13:16:06] | <mig5> | however |
| [13:16:12] | * recidive has quit (Quit: zzz) |
| [13:16:14] | <mig5> | if it had gone to a remote server, its target platform must also have changed |
| [13:16:40] | * mikeholly has left #aegir () |
| [13:16:46] | <mig5> | so, what i want to know is, has it in fact deleted it on server_msater, or has it only (quite rightly) only deleted the copy on the previous platform (which was only on server_master) but now also has it in the copy of the 'target' platform that is also kept locally |
| [13:16:46] | * mikeholly has joined #aegir |
| [13:17:12] | * mikeholly waves |
| [13:18:27] | <xk> | I'll test master->remote, different website hostname |
| [13:18:44] | * EclipseGc has joined #aegir |
| [13:20:19] | <xk> | yeah, master->remote, different website hostname works. |
| [13:20:25] | * mikeholly has left #aegir () |
| [13:22:17] | * eskaypey has joined #aegir |
| [13:23:52] | * eskaypey tip o' the hat |
| [13:23:59] | <mig5> | lol |
| [13:24:21] | <xk> | http://drupal.org/node/1039010 |
| [13:24:23] | <xk> | have a read of that :) |
| [13:24:33] | <mig5> | ta |
| [13:24:36] | <xk> | I did 7 test cases. but I presume the 8th one works. |
| [13:26:15] | <mig5> | the thing i want to know is, in case 1), was it deleted from the master platform where it used to be hosted |
| [13:26:21] | <mig5> | because that's normal, like the other case. |
| [13:26:38] | <mig5> | it should then only exist in the 'platform' that is actually a remote, but is managed from the master |
| [13:27:01] | <xk> | well |
| [13:27:06] | <mig5> | i.e if it was on platform 'master-a' and then you create 'remote-b' and define it as a remote server |
| [13:27:12] | <mig5> | then you mgirate the site frmo master-a |
| [13:27:17] | <xk> | then whats the point of syncing? |
| [13:27:20] | <mig5> | it should be gone from master-a, but exist on both servers in remote-b |
| [13:27:30] | <xk> | in remote-b?!?!? |
| [13:27:34] | <mig5> | of course |
| [13:27:44] | <mig5> | why should it be in master-a, that was a platform on the server_msater server only |
| [13:27:56] | <xk> | I'm lost by "remote-b" |
| [13:27:58] | <mig5> | it effecrtively gets moved into a local copy of what is a remote platform, and is managed/synced from there |
| [13:28:08] | <xk> | where should it be located? |
| [13:28:09] | <mig5> | trying to think how i can explain it more clearly |
| [13:28:17] | <mig5> | what's your remote platform called |
| [13:28:47] | <xk> | web.pressflow-6.20.97 |
| [13:28:49] | <mig5> | right |
| [13:29:21] | <mig5> | so the site should be present in web.pressflow-6.20.97 on both server_master and the remote server. presumably before you mgirated it to this platform, it was in some other platform on the server_master |
| [13:29:34] | <xk> | but why is remote->remote OK, when it's also located on master? |
| [13:30:10] | <mig5> | just read that again ^^ |
| [13:30:13] | <xk> | so where should it be located? master:path-of-platform-on-remote-server ? |
| [13:30:32] | <mig5> | yes |
| [13:30:35] | <xk> | ok |
| [13:30:36] | <mig5> | my point being, before you mgirated it |
| [13:30:40] | <mig5> | it must've been in a different platform |
| [13:30:43] | <xk> | so the problem is. the platform path name is not unique? |
| [13:30:44] | <mig5> | on master |
| [13:30:58] | <mig5> | yes, probably |
| [13:30:59] | <mig5> | but |
| [13:31:08] | <mig5> | how could you have defined the remote platform by the same path |
| [13:31:15] | <mig5> | perhaps that's the bug |
| [13:31:17] | <xk> | well. the path is local to the server |
| [13:31:18] | <xk> | :) |
| [13:31:26] | <mig5> | right |
| [13:31:30] | <mig5> | so i suspect that's our bug |
| [13:31:31] | <xk> | the name of the platform can be anything. |
| [13:31:45] | <mig5> | it's local but if that's to be used to sync to a remote, it should not be used on master for anything else but that |
| [13:31:50] | <xk> | let me add that to the report (the list of platforms and paths) |
| [13:31:52] | <mig5> | yes, the name doesn't matter, the path should matter |
| [13:32:59] | <mig5> | you shouldn't be able to create a platform on master A in /var/aegir/platforms/$someplatform and then define another by the same path to exist on a remote server |
| [13:33:00] | * nlisgo has joined #aegir |
| [13:33:07] | <mig5> | if you can, we should fix that in our hook_validate, in my opinion |
| [13:33:15] | <xk> | yeah |
| [13:34:58] | <xk> | hmmm |
| [13:35:08] | <xk> | are platforms able to be sync'd across servers? |
| [13:35:20] | <mig5> | yes, that does occur |
| [13:35:23] | <xk> | hmm |
| [13:35:24] | <mig5> | well |
| [13:35:26] | <mig5> | hang on |
| [13:35:30] | <xk> | I remember reading that it is not |
| [13:35:31] | <mig5> | do you mean effectively migrate a platform? |
| [13:35:34] | <xk> | because it cannot be bootstraped? |
| [13:35:55] | <mig5> | yeah you can't do that. i thought you meant 'are platforms synced' i.e if you verify your remote platform, is the master copy synced to remote, in which case yes |
| [13:36:03] | <mig5> | but yeah you can't migrate a platform |
| [13:36:07] | <xk> | so when creating a new server |
| [13:36:15] | <xk> | the platform must exist on both the master server, and remote server |
| [13:36:22] | <xk> | and that it must be copied manually to both servers |
| [13:36:23] | <mig5> | yes |
| [13:36:24] | <xk> | yes? |
| [13:36:26] | <xk> | ok. |
| [13:36:26] | <mig5> | well |
| [13:36:29] | <mig5> | not copied manually |
| [13:36:29] | <xk> | that clarifies the situation |
| [13:36:32] | <mig5> | Verify syncs it |
| [13:37:02] | <xk> | hmmm |
| [13:37:03] | <mig5> | if it exists on Master's filesystem, and you create a platform node and say 'this is to be on remote serve'r, that platform on master's filesystem will be synced to the remote |
| [13:37:09] | <mig5> | does that make it clear? |
| [13:37:11] | <xk> | ahhhhhhhhh |
| [13:37:17] | <mig5> | :) |
| [13:37:20] | <xk> | that's probably the step that is causing all the problems for me. |
| [13:37:24] | <mig5> | yes i think so |
| [13:37:28] | <xk> | ok. |
| [13:37:31] | <xk> | so how should it be done? |
| [13:37:46] | <xk> | create platform on MASTER, then migrate to REMOTE? |
| [13:37:50] | <mig5> | like the above (prepare the platform on the master server and then tell aegir it's to be remote) |
| [13:37:53] | * obrienmd has joined #aegir |
| [13:38:03] | <mig5> | then you can install a site on that platform, and that site will get created on master and automaticalyl synced to the remote too |
| [13:38:09] | <xk> | ok |
| [13:38:20] | <mig5> | if you use drush make, you can even skip the part about creating the platform on the master filesystem first |
| [13:38:34] | <xk> | that would explain all the problems. |
| [13:38:35] | <mig5> | in that if you put a makefile in the platform node, it will go and create it automaticalyl on master for you |
| [13:38:38] | <mig5> | and then sync it |
| [13:38:40] | <xk> | but even then, error handling is #1 :) |
| [13:38:43] | <mig5> | yes |
| [13:38:55] | <mig5> | good, we are both understanding each other now i think :) |
| [13:39:23] | <mig5> | and yes we should prevent creating a 'remote' platform if that path already exists on the master but is defined as a 'local' platform already |
| [13:39:34] | <mig5> | that should be quite possibly, because platforms 'belong' to server nodes |
| [13:40:11] | <mig5> | so if there is already a platform's path in the db that has a server node, we should not let you create another one because that 'path' is taken on the master server already |
| [13:40:33] | <xk> | yep |
| [13:40:34] | <mig5> | we should almost have /var/aegir/remote-platforms created on aegir install, maybe that'd also help avoid the issue |
| [13:40:47] | <mig5> | and make /var/aegir/platforms /var/aegir/local-platforms |
| [13:40:51] | <mig5> | but it's symantics |
| [13:40:56] | <mig5> | error checking and documentation should be enough |
| [13:41:03] | <mig5> | semantics* |
| [13:41:23] | <mig5> | i really thought we have a hook_validate already that checks the path and complains, when submitting the platform node |
| [13:41:34] | <mig5> | so i suspect what is happening is it's checking it specific to the server node |
| [13:41:37] | <mig5> | and it should be a global thing |
| [13:42:03] | <mig5> | yep |
| [13:42:04] | <mig5> | if ($node->op != t('Delete') && $result = db_fetch_object(db_query("SELECT n.title AS name FROM {hosting_platform} AS h INNER JOIN {node} AS n ON n.nid = h.nid WHERE publish_path = '%s' AND web_server = %d AND n.nid <> %d AND h.status >= %d", hosting_path_normalize($node->publish_path), $node->web_server, $node->nid, HOSTING_PLATFORM_QUEUED))) { |
| [13:42:10] | <mig5> | 282 form_set_error('publish_path', t('Path already defined in platform %name', array('%name' => $result->name))); |
| [13:42:19] | <mig5> | the key is the 'AND web_server = %d' |
| [13:42:26] | <mig5> | we should just take that out in my opinion |
| [13:42:48] | <xk> | ok |
| [13:43:26] | <mig5> | anarcat: still awake? |
| [13:46:16] | <xk> | so if it's sync'd from master to remote... modules are also sync'd from master? |
| [13:46:20] | * jhedstrom has quit (Ping timeout: 276 seconds) |
| [13:46:27] | <mig5> | yes |
| [13:46:33] | <xk> | so this is full master management of the filesystem for remote servers? |
| [13:46:37] | <mig5> | and that is the recommended way |
| [13:46:38] | <mig5> | yes |
| [13:46:40] | <xk> | iow: no one needs direct access to the remote servers |
| [13:46:46] | * ezra-g has joined #aegir |
| [13:46:53] | <xk> | ok. |
| [13:46:55] | <mig5> | so that the aegir master node can keep in touch with what modules exist (so it can handle migrations properly, knowing which target platforms are valid) |
| [13:46:59] | * ezra-g has quit (Client Quit) |
| [13:47:07] | <xk> | now it's making sense. |
| [13:47:19] | * jlkinsel has joined #aegir |
| [13:47:36] | <mig5> | that's why it surprises people that they edit the theme directly on the remote site, and a verify blows away their changes :) |
| [13:47:41] | <mig5> | because that change didn't exist on the masster server's copy |
| [13:47:58] | <jlkinsel> | hey guys - curious if anybody's thought of this - if I use aegir+ubercart, is there a way to automatically provide ftp access for users? |
| [13:48:15] | <xk> | mig5: so about what updatedb? |
| [13:48:18] | <mig5> | sure there is, you'd have to write an FTP feature though :) |
| [13:48:23] | <jlkinsel> | he |
| [13:48:24] | <jlkinsel> | h |
| [13:48:24] | <mig5> | xk: that is handled on migrate |
| [13:48:27] | <mig5> | so that's why the best workflow is |
| [13:48:32] | <mig5> | to build new platforms with the updated code |
| [13:48:34] | <mig5> | and do migrations |
| [13:48:41] | <mig5> | if it goes wrong hopefully you can also then rely on rollback |
| [13:48:55] | <xk> | what about updating modules... just verify and it updates the platform, and the sites that use the module? |
| [13:49:14] | <mig5> | yes but that's why doing it by way of a migration to a new target build is smarter |
| [13:49:24] | <mig5> | you end up on new code and you've invoked drush updatedb because Migrate does it for you |
| [13:49:30] | <mig5> | and it took a backup first |
| [13:49:31] | <mig5> | :) |
| [13:49:46] | <mig5> | if it goes bad you can then just click Restore and go back to the old platform |
| [13:49:47] | <mig5> | and old db |
| [13:50:03] | <xk> | so when updating modules, a new platform should be created? |
| [13:50:14] | <mig5> | in my opinion, yes it's the best way |
| [13:50:17] | <xk> | ok |
| [13:50:23] | <xk> | yeah, I agree with that |
| [13:50:43] | <xk> | I've seen in non-drupal custom-cms instances where handling modules was a nightmare :) |
| [13:52:54] | <mig5> | hehe |
| [13:53:13] | <xk> | "lets upgrade everyone to the latest xyz module" |
| [13:53:19] | <xk> | "oh shit, we customised that module for customer x" |
| [13:53:38] | <mig5> | creating new builds and doing migrations is also cumbersome and can be slow, and people thus like to tell me i'm crazy :) but i am still convinced it's the most elegant and safe way |
| [13:53:51] | <mig5> | and it's got easier actually: have a read of http://lists.aegirproject.org/pipermail/aegir/2011-January/000026.html |
| [13:53:59] | <mig5> | you can create the platform and create the platform *node* all from the command line now |
| [13:54:03] | <mig5> | with hosting-import |
| [13:54:11] | * eskaypey has left #aegir () |
| [13:54:14] | <mig5> | you're a sysadmin: so you know this means you can script it too :) |
| [13:54:18] | <mig5> | and cron it even, for iterative tests! :) |
| [13:54:38] | <mig5> | the only thing you can't do yet |
| [13:54:41] | <mig5> | is do a migrate from the command line |
| [13:54:48] | <mig5> | because hosting-task can't take arguments (yet) |
| [13:54:50] | <mig5> | there's a ticket for that |
| [13:55:12] | <mig5> | once you can do that, you need never use the GUI again, you could do your upgrades via a script, even in a post-commit hook in git after you've pushed new code |
| [13:55:23] | <xk> | heh |
| [13:55:52] | <mig5> | so it almost becomes like Hudson, it'd attempt the migrate (upgrade) and if it fail s, you can look at it, but it should all be unattended |
| [13:58:03] | <mig5> | i'm thinking of editing that hook_validate so that there's two checks |
| [13:58:19] | <mig5> | if the existing one is hit, we report 'this path is already in use by another platform on this server' |
| [13:58:38] | <mig5> | if the webserver nid is different, the message could be 'this path is already reserved by a platform on a remote server' |
| [13:58:59] | <mig5> | helps to make it clear what's going on, and what the correct behaviour is meant to be (maybe) |
| [13:59:15] | <xk> | ;) |
| [13:59:26] | <mig5> | but it's hard because now you understand it |
| [13:59:33] | <mig5> | so you can't tell me if that would have made it all make immediate sense to you :) |
| [13:59:42] | <mig5> | we'll have to find another victim |
| [13:59:48] | * eft has left #aegir () |
| [14:00:09] | * eft has joined #aegir |
| [14:00:50] | * unconed has quit (Ping timeout: 240 seconds) |
| [14:01:03] | <mig5> | maybe i can simplifiy it with the one check and have it say 'A platform already exists with this path. Platform paths (on local or remote servers) must be unique.' |
| [14:01:17] | <jlittlew> | hi all -- goofy question. I messed up installing when setting up my frontend url how should I change it? run the reset? I don't quite get how to do that... |
| [14:01:19] | <mig5> | instead of the current 'Path already defined in platform %name' |
| [14:01:50] | <mig5> | jlittlew: awkward, there are a few places you could change it in the database and on the filesystem, but that's fiddly and you might miss one of the spots |
| [14:01:52] | * lukus has quit (Ping timeout: 240 seconds) |
| [14:01:56] | <mig5> | it is probably easier to blow it away and reinstall |
| [14:02:02] | <mig5> | we have docs to do a complete removal of aegir |
| [14:02:08] | * unconed has joined #aegir |
| [14:02:10] | <mig5> | don't run the reset script it is very old and won't work probably :) |
| [14:02:10] | <jlittlew> | will do. |
| [14:02:12] | <jlittlew> | thanks |
| [14:02:23] | <mig5> | http://community.aegirproject.org/uninstalling |
| [14:03:34] | <jlittlew> | mig5: got it, thanks |
| [14:05:04] | * unconed has quit (Client Quit) |
| [14:13:07] | * SandCube has joined #aegir |
| [14:13:14] | <jlittlew> | mig5: working now, thanks |
| [14:13:20] | <mig5> | np |
| [14:13:42] | * nlisgo has quit (Quit: nlisgo) |
| [14:16:43] | * mikejoconnor has quit (Quit: mikejoconnor) |
| [14:24:09] | * q0rban has quit (Quit: Computer has gone to sleep.) |
| [14:26:39] | * scientist has quit (Ping timeout: 240 seconds) |
| [14:32:45] | * fastdesign has quit () |
| [14:33:49] | <xk> | moving the publish path broke all the sites ;) |
| [14:33:57] | * jlittlew has left #aegir () |
| [14:34:02] | <mig5> | :) |
| [14:34:06] | * unconed has joined #aegir |
| [14:34:09] | <mig5> | Migrate! |
| [14:34:31] | <xk> | I reckon the publish path should not be possible to change, after the platform is created |
| [14:34:53] | <mig5> | not a bad argument |
| [14:35:00] | <mig5> | it's a job for Migrate to move shit around |
| [14:35:32] | <mig5> | we could lock it down in the UI but people could still go around abd break stuff in the backend though |
| [14:35:34] | <mig5> | by editing the aliases etc |
| [14:35:43] | <mig5> | there's only so much we can do to protect people from themselves :) |
| [14:35:46] | <xk> | yeah |
| [14:36:25] | <mig5> | i really like the idea of scheduled tasks, i would like to see Verify being run almost like it was puppetmaster checking a node |
| [14:36:30] | <mig5> | routine 'that doesn't look right' and fix it up |
| [14:38:23] | <xk> | hah. now I broke it big time. |
| [14:38:33] | <xk> | The external command could not be executed due to an application error. |
| [14:39:04] | <xk> | :( |
| [14:40:06] | <xk> | mig5: it should not be possible to break the install via the UI. that should be the aim. |
| [14:40:21] | <xk> | or very basic backend commands (copying files around) |
| [14:41:48] | <mig5> | do you want to open a feature request in Hosting |
| [14:41:55] | <mig5> | to lock down the publish path |
| [14:41:58] | <xk> | ok |
| [14:44:42] | <xk> | lol |
| [14:44:45] | <xk> | now i've really broken it |
| [14:44:48] | <xk> | can't even create sites |
| [14:48:53] | <mig5> | not sure what happened there.. check your drush aliases |
| [14:48:58] | <mig5> | and the drushrc.php files of your platforms and sites |
| [14:49:03] | <mig5> | make sure the paths etc are as expected |
| [14:50:47] | <xk> | hmm |
| [14:50:47] | <xk> | fun fun fun |
| [14:50:53] | <xk> | I dont like it when the database is removed |
| [14:51:00] | <mig5> | that's interesting |
| [14:51:02] | <xk> | makes it much harder to recover |
| [14:51:20] | <mig5> | i don't think a path change would have caused that.. but i don't know, didn't see what was run |
| [14:51:23] | <xk> | delete should not complain that the DB does not exist any more |
| [14:51:30] | <xk> | and error out |
| [14:51:34] | <mig5> | dunno |
| [14:51:40] | <mig5> | really need context on what was being run |
| [14:51:47] | <xk> | I tried to do verify |
| [14:51:55] | <xk> | verify after changing publish path |
| [14:52:00] | <mig5> | verify doesn't run any delete hooks |
| [14:52:43] | <mig5> | it just looks at packages and regenerates the settings.php, drushrc.php, and the apache vhost |
| [14:53:15] | * eft has quit (Ping timeout: 265 seconds) |
| [14:54:46] | <mig5> | but yes failing to drop the db is just a warning |
| [14:54:59] | <mig5> | for some reason |
| [14:55:15] | <mig5> | possibly to force it through if the db never got created on install but someone is trying to delete the failed attempt, dunno |
| [14:55:55] | <mig5> | confused by what oyu want though, you said you don't like it being removed, but that it should error out if it can't delete it |
| [14:56:04] | <mig5> | i.e if it's not there |
| [14:56:16] | <xk> | hmm |
| [14:56:21] | <xk> | good point. I dont know what I was thinking |
| [14:56:23] | <mig5> | if it wasn't there already that's strange and not the delete task's fault |
| [14:56:39] | <xk> | it must have been a different problem |
| [14:56:42] | <mig5> | was all this done in the UI? do you have task logs identifying where a delete took place? |
| [14:56:44] | <xk> | but I just blamed it on the db warning |
| [14:56:48] | <mig5> | maybe it was a migrate |
| [14:57:11] | <mig5> | that failed |
| [14:57:18] | <mig5> | (which is why migrate invokes provision-backup first) |
| [14:57:26] | <mig5> | should have a tarball in /var/aegir/backups at least |
| [14:57:31] | <xk> | lol |
| [14:57:33] | <mig5> | which will have a database.sql in it |
| [14:57:34] | <xk> | this is broken |
| [14:57:41] | <xk> | The external command could not be executed due to an application error. |
| [14:57:50] | <mig5> | yes that's drush being awesome with its error reporting |
| [14:57:56] | <mig5> | i suspect something in the alias is askew |
| [14:58:02] | <mig5> | in /var/aegir/.drush |
| [14:58:08] | <mig5> | or similar in the drushrc.php |
| [14:58:15] | <mig5> | run it from cli with --debug |
| [14:58:21] | * nomad411 has joined #aegir |
| [14:59:03] | * realityloop has joined #aegir |
| [15:05:11] | <CIA-27> | aegir/provision: mig * r3d7ff4152b73 /upgrade.sh.txt: #1037222 upgrade.sh and upgrade.txt ambiguous about drush and drush make versions |
| [15:13:27] | * Irishgringo has quit (Ping timeout: 240 seconds) |
| [15:17:54] | * Met4physica has quit (Remote host closed the connection) |
| [15:25:21] | * nomad411 has quit (Quit: Back to the unreal world...) |
| [15:26:37] | * EclipseGc has quit (Quit: EclipseGc) |
| [15:33:28] | <xk> | heh. attempt to disable a site. it fails |
| [15:33:30] | <xk> | try it again. it works |
| [15:34:18] | <mig5> | can't reproduce :) |
| [15:34:48] | <CIA-27> | aegir/hostmaster: mig * r6cb6770e7763 /modules/hosting/server/hosting_server.module: #959852 Add new server confirmation text indicates wrong server type |
| [15:43:17] | <xk> | need to run verify after updating drushrc due to platform publish path changes |
| [15:44:40] | <CIA-27> | aegir/hostmaster: mig * r772cd8c2b5e8 /modules/hosting/server/hosting_server.module: don't allow servers to have the same hostname. breaks contexts. |
| [15:48:15] | <CIA-27> | aegir/hostmaster: mig * r5c93918e3c53 /modules/hosting/server/hosting_server.module: a drupal_set_message was missing its variable substitution |
| [15:54:58] | * obrienmd has quit (Quit: Leaving.) |
| [15:58:56] | * obrienmd has joined #aegir |
| [16:11:56] | * beautifulmind has joined #aegir |
| [16:13:01] | * boztek has joined #aegir |
| [16:21:17] | <hefring> | community => Any way to use Aegir on Mutu Server with no root access, but with an api for the domain/sql creating => http://community.aegirproject.org/node/272 |
| [16:21:17] | * SandCube has quit () |
| [16:22:42] | <jlkinsel> | mig5: is there politics or something behind pointing aegirproject.org to g.d.o? |
| [16:25:53] | <mig5> | i wouldn't say politics, just slow going |
| [16:25:59] | <mig5> | or other priorities |
| [16:26:03] | <jlkinsel> | gotchya |
| [16:49:14] | * nick_santa has quit (Quit: nick_santa) |
| [16:53:46] | * realityloop has quit (Remote host closed the connection) |
| [16:59:07] | * boztek has quit (Remote host closed the connection) |
| [17:04:39] | * totten has quit (Ping timeout: 240 seconds) |
| [17:17:40] | * totten has joined #aegir |
| [17:27:13] | * EndEd has quit () |
| [17:47:58] | * obrienmd has quit (Quit: Leaving.) |
| [17:55:02] | * eft has joined #aegir |
| [17:55:14] | * beautifulmind has quit (Read error: Connection reset by peer) |
| [17:55:56] | * beautifulmind has joined #aegir |
| [18:02:15] | * kylemathews has quit (Ping timeout: 240 seconds) |
| [18:03:09] | * jfreeman has quit (Remote host closed the connection) |
| [18:05:51] | * sepehr has joined #aegir |
| [18:06:04] | * jlkinsel has left #aegir () |
| [18:13:04] | * secoif has quit (Quit: secoif) |
| [18:20:54] | * ngnp has joined #aegir |
| [18:23:27] | * beautifulmind has quit (Ping timeout: 240 seconds) |
| [18:24:47] | * ngnp_ has joined #aegir |
| [18:25:53] | * sepehr has quit (Ping timeout: 240 seconds) |
| [18:27:25] | * ngnp has quit (Ping timeout: 260 seconds) |
| [18:27:25] | * ngnp_ is now known as ngnp |
| [18:42:48] | * sepehr has joined #aegir |
| [19:14:03] | * Haza`Aw is now known as Haza` |
| [19:17:34] | * anarcat has quit (Ping timeout: 250 seconds) |
| [19:17:40] | * anarcat has joined #aegir |
| [19:30:35] | * eft has left #aegir () |
| [19:31:41] | * Haza` is now known as Haza`Aw |
| [19:40:22] | * jonhattan has joined #aegir |
| [19:44:49] | * jackinloadup has joined #aegir |
| [19:44:53] | * jonhattan has quit (Ping timeout: 240 seconds) |
| [19:46:59] | * siliconmeadow has joined #aegir |
| [19:47:12] | * jonhattan has joined #aegir |
| [19:47:48] | * NeoID has quit (Quit: Forlater kanalen) |
| [19:53:16] | <jackinloadup> | anyone know where i should look for documentation on how to configure bind to load aegirs config files? |
| [20:02:38] | * Artusamak_afk is now known as Artusamak |
| [20:04:14] | * Haza`Aw is now known as Haza` |
| [20:06:56] | * yareckon has joined #aegir |
| [20:22:11] | * capitan has quit (Ping timeout: 276 seconds) |
| [20:24:59] | * capitan has joined #aegir |
| [20:33:51] | * unconed has left #aegir () |
| [20:37:52] | * beautifulmind has joined #aegir |
| [20:43:54] | * jackinloadup has quit (Read error: Operation timed out) |
| [20:44:51] | * jackinloadup has joined #aegir |
| [20:47:07] | * jackinloadup_ has joined #aegir |
| [20:49:17] | * jackinloadup has quit (Ping timeout: 246 seconds) |
| [20:49:18] | * jackinloadup_ is now known as jackinloadup |
| [20:49:56] | * adrinux has joined #aegir |
| [20:53:17] | * mikgreen has joined #aegir |
| [20:54:28] | * mikgreen has quit (Client Quit) |
| [20:55:12] | * mikgreen has joined #aegir |
| [20:55:19] | * mikgreen has quit (Client Quit) |
| [21:06:22] | * recidive has joined #aegir |
| [21:17:47] | * redShadow[2V] has joined #aegir |
| [21:26:09] | * NeoID has joined #aegir |
| [21:28:01] | * mrchrisadams has joined #aegir |
| [21:29:37] | * parsingphase has joined #aegir |
| [21:57:31] | * jackinloadup has quit (Quit: jackinloadup) |
| [21:59:14] | * sepehr has quit (Ping timeout: 240 seconds) |
| [22:01:55] | * mrchrisadams has quit (Quit: mrchrisadams) |
| [22:02:21] | * mrchrisadams has joined #aegir |
| [22:05:46] | * mrchrisadams has quit (Read error: Connection reset by peer) |
| [22:45:26] | * beautifulmind1 has joined #aegir |
| [22:45:50] | * beautifulmind has quit (Ping timeout: 260 seconds) |
| [22:48:15] | <hefring> | community => One site per project, or multiple? => http://community.aegirproject.org/node/273 |
| [22:52:00] | * psynaptic|afk is now known as psynaptic |
| [22:52:00] | * psynaptic has quit (Changing host) |
| [22:52:00] | * psynaptic has joined #aegir |
| [22:59:58] | * lolmaus has joined #aegir |
| [23:05:02] | * noecc has joined #aegir |
| [23:11:27] | * beautifulmind1 has quit (Ping timeout: 240 seconds) |
| [23:12:38] | * mrchrisadams has joined #aegir |
| [23:21:14] | * Vertice has quit (Quit: Vertice) |
| [23:30:45] | * sepehr has joined #aegir |
| [23:36:32] | * beautifulmind has joined #aegir |
| [23:44:56] | * sepehr has quit (Read error: Connection reset by peer) |
| [23:48:20] | * Chipie has left #aegir () |
| [00:01:18] | * noecc has left #aegir ("pax") |
| [00:03:04] | * j0nathan has quit (Quit: ¡ Hasta luego !) |
| [00:03:26] | * sepehr has joined #aegir |
| [00:06:41] | * mikejoconnor has joined #aegir |
| [00:09:55] | * penyaskito has quit (Ping timeout: 240 seconds) |
| [00:16:25] | * sepehr has quit (Read error: Connection reset by peer) |
| [00:16:28] | * sepehr1 has joined #aegir |
| [00:27:47] | * psynaptic is now known as psynaptic|break |
| [00:31:46] | * szczym has joined #aegir |
| [00:38:25] | * psynaptic|break is now known as psynaptic |
| [00:46:31] | * penyaskito has joined #aegir |
| [00:46:40] | * MadTBone has joined #aegir |
| [00:51:56] | * mikejoconnor_ has joined #aegir |
| [00:57:14] | * noecc has joined #aegir |
| [01:02:16] | * shrop has joined #aegir |
| [01:09:03] | * ergonlogic has quit (Ping timeout: 240 seconds) |
| [01:09:48] | * ezra-g has joined #aegir |
| [01:12:21] | * EclipseGc has joined #aegir |
| [01:15:38] | * rteijeiro has joined #aegir |
| [01:17:44] | * adrinux has quit (Ping timeout: 246 seconds) |
| [01:20:55] | * fremo__ has quit (Read error: Connection reset by peer) |
| [01:22:52] | * killes has quit (Ping timeout: 250 seconds) |
| [01:23:48] | * adrinux has joined #aegir |
| [01:23:51] | * NeoID has quit (Ping timeout: 240 seconds) |
| [01:24:52] | * killes has joined #aegir |
| [01:27:19] | * fremo__ has joined #aegir |
| [01:28:00] | * j0nathan has joined #aegir |
| [01:29:48] | * mattmcmanus has joined #aegir |
| [01:29:57] | * mcmanusm has quit (Quit: That's it! I QUIT! I can't take it anymore!) |
| [01:32:45] | * adrinux has quit (Ping timeout: 276 seconds) |
| [01:37:39] | * adrinux has joined #aegir |
| [01:38:11] | * scientist has joined #aegir |
| [01:38:50] | * psynaptic is now known as psynaptic|break |
| [01:53:44] | * penyaskito has quit (Quit: Saliendo) |
| [01:54:01] | * q0rban has joined #aegir |
| [01:57:27] | * totten has quit (Ping timeout: 240 seconds) |
| [02:02:53] | * totten has joined #aegir |
| [02:11:26] | * sepehr1 has quit (Quit: Leaving.) |
| [02:12:44] | * psynaptic|break is now known as psynaptic |
| [02:13:51] | * totten has quit (Ping timeout: 240 seconds) |
| [02:17:49] | * xk has quit (Quit: *Use*BitchX.*Yes*this*is*a*subliminal*message.*) |
| [02:19:58] | * totten has joined #aegir |
| [02:22:58] | * EugenMayer has joined #aegir |
| [02:26:18] | * ezra-g is now known as ezra-g|brb |
| [02:34:45] | * NeoID has joined #aegir |
| [02:37:20] | * jonhattan has quit (Ping timeout: 272 seconds) |
| [02:38:30] | * jackinloadup has joined #aegir |
| [02:38:43] | * jonhattan has joined #aegir |
| [02:43:39] | * obrienmd has joined #aegir |
| [02:48:41] | * ezra-g|brb is now known as ezra-g |
| [02:49:57] | * jonhattan_ has joined #aegir |
| [02:50:25] | * jackinloadup has quit (Quit: jackinloadup) |
| [02:52:26] | * beautifulmind has quit (Quit: Leaving.) |
| [02:53:29] | * jonhattan_ has quit (Remote host closed the connection) |
| [03:03:04] | * mikejoconnor_ has quit (Quit: mikejoconnor_) |
| [03:08:08] | * mikejoconnor_ has joined #aegir |
| [03:08:09] | * Brandonian has joined #aegir |
| [03:08:14] | * mikejoconnor_ has left #aegir () |
| [03:13:53] | * adrinux has quit (Ping timeout: 255 seconds) |
| [03:14:32] | * kim-day has quit (Quit: kim-day) |
| [03:16:13] | * ergonlogic has joined #aegir |
| [03:19:50] | * parsingphase has quit (Read error: Connection reset by peer) |
| [03:20:27] | * adrinux has joined #aegir |
| [03:28:10] | * MadTBone has quit (Ping timeout: 240 seconds) |
| [03:31:53] | * Vertice has joined #aegir |
| [03:38:29] | * jhedstrom has joined #aegir |
| [03:39:15] | * adrinux has quit (Ping timeout: 260 seconds) |
| [03:45:37] | * ngnp has quit (Quit: ngnp) |
| [03:48:36] | * siliconmeadow has quit (Remote host closed the connection) |
| [03:48:48] | * lolmaus has quit () |
| [03:49:36] | * adrinux has joined #aegir |
| [03:54:15] | * jhedstrom has quit (Ping timeout: 240 seconds) |
| [03:56:57] | * kylemathews has joined #aegir |
| [03:57:16] | * jhedstrom has joined #aegir |
| [04:03:12] | * Haza` is now known as Haza`Aw |
| [04:04:04] | * MadTBone has joined #aegir |
| [04:04:42] | * Slydder1 has joined #aegir |
| [04:06:49] | * ezra-g is now known as ezra-g|afk |
| [04:08:41] | * Irishgringo has joined #aegir |
| [04:13:49] | * MadTBone has quit (Ping timeout: 255 seconds) |
| [04:14:55] | * ryanarmstrong has joined #aegir |
| [04:16:41] | * ryanarmstrong has quit (Client Quit) |
| [04:18:57] | * j0nathan has quit (Quit: ¡ Hasta luego !) |
| [04:21:26] | * lukus has joined #aegir |
| [04:22:15] | * ryanarmstrong has joined #aegir |
| [04:27:02] | * j0nathan has joined #aegir |
| [04:27:50] | * redShadow[2V] has quit (Quit: Leaving) |
| [04:43:25] | * kylemathews has quit (Ping timeout: 260 seconds) |
| [04:45:16] | * bertodsera has quit (Ping timeout: 272 seconds) |
| [04:48:10] | * kylemathews has joined #aegir |
| [04:50:52] | * ergonlogic has quit (Ping timeout: 240 seconds) |
| [05:00:06] | * ergonlogic has joined #aegir |
| [05:00:32] | * Chipie has joined #aegir |
| [05:11:11] | * kim-day has joined #aegir |
| [05:11:14] | * jhedstrom has quit (Ping timeout: 240 seconds) |
| [05:12:24] | * josh_k has joined #aegir |
| [05:12:24] | * josh_k has quit (Changing host) |
| [05:12:24] | * josh_k has joined #aegir |
| [05:13:28] | * nicholasalipaz has joined #aegir |
| [05:14:50] | * jhedstrom has joined #aegir |
| [05:15:38] | * bertodsera has joined #aegir |
| [05:18:36] | * EugenMayer has quit (Quit: Leaving.) |
| [05:22:20] | * szczym has quit (Quit: Wychodzi) |
| [05:26:32] | * jonhattan has quit (Read error: No route to host) |
| [05:27:20] | * Chipie has quit (Quit: Leaving.) |
| [05:27:37] | * rteijeiro has quit (Remote host closed the connection) |
| [05:27:56] | * jonhattan has joined #aegir |
| [05:29:33] | * Artusamak is now known as Artusamak_afk |
| [05:30:46] | * scientist has quit (Ping timeout: 255 seconds) |
| [05:31:34] | * Met4physica has joined #aegir |
| [05:32:23] | * adrinux has quit (Quit: Leaving.) |
| [05:32:33] | <Met4physica> | anyone familiar with how to set up a verisign ssl certificate with nginx? |
| [05:34:12] | <Deezire> | You follow their instructions? |
| [05:34:20] | * Chipie has joined #aegir |
| [05:35:18] | <Met4physica> | i got the certificate installed |
| [05:35:24] | <Met4physica> | but i can't figure out how the intermediate bundle is installed |
| [05:36:01] | <Met4physica> | the SSLCertificateChainFile |
| [05:36:23] | * yareckon has quit (Quit: yareckon) |
| [05:36:57] | <Met4physica> | can i concatenate it with my .crt file? |
| [05:37:05] | * joestewart|afk is now known as joestewart |
| [05:37:06] | <Met4physica> | or does it load seperately in my nginx site config |
| [05:37:54] | <joestewart> | seems I remember omega8cc saying to concatenate |
| [05:38:53] | <Met4physica> | can't hurt to try :) |
| [05:40:25] | <Met4physica> | http://wiki.nginx.org/HttpSslModule#Synopsis #nginx helped me |
| [05:40:32] | <Met4physica> | joestewart you were correct it looks like |
| [05:42:09] | <Met4physica> | why do i have /config/ssl.d/ and :~/config/server_master/ssl.d ? |
| [05:48:22] | * scientist has joined #aegir |
| [05:54:51] | * jcapelo has joined #aegir |
| [05:55:41] | <jcapelo> | when setting $AEGIR_HOST in /etc/hosts for 127.0.0.1 I still cant resolveip $AEGIR_HOST |
| [05:55:45] | <jcapelo> | any ideas/ |
| [05:55:55] | * NeoID has quit (Quit: Forlater kanalen) |
| [05:58:50] | * ezra-g|afk is now known as ezra-g |
| [06:00:43] | * SandCube has joined #aegir |
| [06:04:55] | * psynaptic is now known as psynaptic|food |
| [06:18:23] | * NeoID has joined #aegir |
| [06:21:10] | * mrchrisadams has quit (Quit: mrchrisadams) |
| [06:28:24] | * psynaptic|food is now known as psynaptic |
| [06:36:20] | * ezra-g has quit (Quit: ezra-g) |
| [06:38:08] | <SandCube> | mig5, do you remember that problem I was having on installing modules using Drupal7's web interface asking for FTP user? |
| [06:39:03] | * Irishgringo has quit (Ping timeout: 240 seconds) |
| [06:39:25] | <SandCube> | I did some tests and realized it only happens if I do "drush site-install" if I install using the web it does not happen |
| [06:54:33] | * Haza`Aw is now known as Haza` |
| [06:55:59] | * Artusamak_afk is now known as Artusamak |
| [06:56:01] | * ezra-g has joined #aegir |
| [07:07:56] | * mikejoconnor has quit (Quit: mikejoconnor) |
| [07:15:21] | * penyaskito has joined #aegir |
| [07:15:31] | * noecc has left #aegir ("pax") |
| [07:18:12] | * noecc has joined #aegir |
| [07:31:32] | * sepehr has joined #aegir |
| [07:39:51] | * sepehr1 has joined #aegir |
| [07:43:25] | * sepehr has quit (Ping timeout: 265 seconds) |
| [07:44:07] | * sepehr1 has quit (Client Quit) |
| [07:44:27] | * bertodsera has quit (Remote host closed the connection) |
| [07:50:56] | * milk has joined #aegir |
| [07:57:39] | * bertodsera has joined #aegir |
| [08:03:41] | * scientist has quit (Ping timeout: 264 seconds) |
| [08:05:27] | * Irishgringo has joined #aegir |
| [08:17:59] | * ezra-g has quit (Quit: ezra-g) |
| [08:18:56] | * ezra-g has joined #aegir |
| [08:26:55] | * psynaptic is now known as psynaptic|break |
| [08:26:58] | <jcapelo> | in the apache configuration part of the aegir install |
| [08:26:58] | <jcapelo> | Shell commands as root:: |
| [08:26:59] | <jcapelo> | a2enmod rewrite |
| [08:26:59] | <jcapelo> | ln -s /var/aegir/config/apache.conf /etc/apache2/conf.d/aegir.conf |
| [08:27:48] | <jcapelo> | by these point should i have aegir downloaded and does it matter that i dont have that path: /etc/apache2/conf.d but /etc/conf.d/apache2 ?? |
| [08:27:58] | * scientist has joined #aegir |
| [08:28:58] | * mikejoconnor has joined #aegir |
| [08:35:36] | * ergonlogic has quit (Ping timeout: 240 seconds) |
| [08:41:15] | * shrop has quit (Quit: shrop) |
| [08:43:27] | * Slydder1 has quit (Quit: Leaving.) |
| [08:47:31] | * ezra-g has quit (Quit: ezra-g) |
| [08:50:10] | * bertodsera has quit (Read error: Connection reset by peer) |
| [08:51:28] | * jonhattan has quit (Quit: Ex-Chat) |
| [08:52:23] | * Brandonian has quit (Quit: Brandonian) |
| [08:52:37] | * bertodsera has joined #aegir |
| [08:54:07] | * nicholasalipaz has quit (Ping timeout: 246 seconds) |
| [09:00:28] | * bertodsera has quit (Ping timeout: 255 seconds) |
| [09:04:20] | * osvaldo has joined #aegir |
| [09:11:28] | * mlncn has quit (Remote host closed the connection) |
| [09:22:03] | * eft_ has joined #aegir |
| [09:25:27] | * mlncn has joined #aegir |
| [09:30:37] | * scientist has quit (Ping timeout: 255 seconds) |
| [09:33:38] | * nomad411 has joined #aegir |
| [09:47:51] | * totten has quit (Ping timeout: 240 seconds) |
| [09:54:10] | * bertodsera has joined #aegir |
| [09:54:49] | * jackinloadup has joined #aegir |
| [09:55:32] | <jackinloadup> | can anyone point me to some documentation on setting up aegir to work with bind? |
| [09:55:34] | * FransK has quit (Remote host closed the connection) |
| [09:56:16] | * adrinux has joined #aegir |
| [10:00:24] | * mlncn has quit (Ping timeout: 276 seconds) |
| [10:00:27] | * realityloop has joined #aegir |
| [10:04:10] | * totten has joined #aegir |
| [10:06:38] | <SandCube> | jackinloadup: http://groups.drupal.org/node/16862 |
| [10:07:36] | <jackinloadup> | SandCube, Thanks! thats exactly what i was looking for. |
| [10:08:09] | <SandCube> | jackinloadup: what is your OS? |
| [10:08:34] | * anarcat has quit (Quit: offline. it's good to be.) |
| [10:09:47] | <jackinloadup> | SandCube, Ubuntu |
| [10:10:31] | <SandCube> | jackinloadup: me too |
| [10:12:02] | <jackinloadup> | SandCube, have you had any luck finding a reasonable way to deal with debian/ubuntu not including the correct branch of GD with the php-gd package. |
| [10:12:44] | <jackinloadup> | SandCube, Drupal complains about it. At least D7 does |
| [10:12:51] | <SandCube> | jackinloadup: what do you mean? |
| [10:12:58] | <SandCube> | I had no problems |
| [10:13:21] | <SandCube> | are you using the package manager to install or command prompt? |
| [10:13:39] | <eft_> | jackinloadup: I think that's a false positive error |
| [10:13:59] | <SandCube> | my D7 sites dont complain about it |
| [10:14:08] | <SandCube> | I installed by command line |
| [10:14:16] | * q0rban is now known as q0rban|afk |
| [10:15:47] | * mlncn has joined #aegir |
| [10:15:58] | <ryanarmstrong> | Quick question, does Aegir put anything into the database of a Drupal site you create within Aegir? I ask because I am wanting to bring in some Drupal sites I have that I made as a standalone site, before our new Aegir server was setup. Could I simply create the appropirate platform, create a site on that plat, copy over the theme and modules from the old site, and then do a database dump of the iste, drop the Ageir db, |
| [10:17:09] | <eft_> | jackinloadup: maybe this will help http://drupal.org/node/878778 |
| [10:17:11] | <SandCube> | jackinloadup: what is your ubuntu version? I'm on 10.04 |
| [10:18:17] | <jackinloadup> | SandCube, here is the error im getting http://pastebin.com/m8QRsPnp |
| [10:19:12] | <eft_> | jackinloadup: actually strike that advice - I may be mixing GD and imagemagick |
| [10:19:30] | * obrienmd has quit (Quit: Leaving.) |
| [10:19:59] | <jackinloadup> | SandCube, Ubuntu 10.04.1 LTS |
| [10:20:58] | <SandCube> | jackinloadup: strange, it should work out of the box. Unless you added repositories to your ubuntu |
| [10:21:37] | <SandCube> | check the topig eft_: said ^^ |
| [10:21:58] | <jackinloadup> | SandCube, i don't believe so sources.list looks normal |
| [10:21:59] | <jackinloadup> | hmm |
| [10:23:26] | <jackinloadup> | SandCube, here is the bug report relating to that issue https://bugs.launchpad.net/ubuntu/+source/php5/+bug/74647 |
| [10:23:52] | * recidive has quit (Quit: zzz) |
| [10:24:50] | * recidive has joined #aegir |
| [10:25:02] | * mlncn has quit (Remote host closed the connection) |
| [10:25:56] | * fysa_ has joined #aegir |
| [10:26:25] | * fysa_ has quit (Quit: fysa_) |
| [10:26:39] | <SandCube> | jackinloadup: if you use the one from the official repos you will fine. LTS on 10.04.1 LTS means Long Term Service = the OS will only download very safe packages. Probably you included a non official repo |
| [10:27:36] | <jackinloadup> | i see |
| [10:29:02] | * fysa_ has joined #aegir |
| [10:29:19] | * recidive has quit (Ping timeout: 246 seconds) |
| [10:29:56] | * j0nathan has quit (Quit: ¡ Hasta luego !) |
| [10:35:26] | * Artusamak is now known as Artusamak_afk |
| [10:38:04] | <realityloop> | jackinloadup: http://realityloop.com/blog/2009/05/24/fixing-gd-image-rotation-drupal-6... |
| [10:38:30] | <realityloop> | I imagine it will work on newer versions of Ubuntu/Debian |
| [10:39:01] | * fysa_ has quit (Ping timeout: 255 seconds) |
| [10:39:58] | <jackinloadup> | realityloop, thanks i will look into this |
| [10:44:48] | * mrfelton has quit (Quit: mrfelton) |
| [10:45:38] | * joestewart is now known as joestewart|afk |
| [10:45:38] | * fysa has joined #aegir |
| [10:45:51] | * Haza` is now known as Haza`Aw |
| [10:51:21] | * mlncn has joined #aegir |
