| [10:00:41] | * rominronin has joined #aegir |
| [10:06:03] | * rominronin has quit (Ping timeout: 250 seconds) |
| [10:19:26] | <realityloop> | is there a way to provide the mysql password in the hostmaster-install command, and not promy for continuing install? |
| [10:21:33] | * Egyptian[Home] has joined #aegir |
| [10:23:25] | <realityloop> | ok, fount the providing DB pass, but can't see a flag to proceed without prompt.. |
| [10:36:56] | * realityloop has quit (Remote host closed the connection) |
| [10:50:40] | * Egyptian[Home] has quit (Ping timeout: 260 seconds) |
| [10:55:28] | * Egyptian[Home] has joined #aegir |
| [11:02:07] | * rominronin has joined #aegir |
| [11:07:29] | * rominronin has quit (Ping timeout: 260 seconds) |
| [11:43:11] | * inteja_ has quit (Ping timeout: 276 seconds) |
| [11:56:54] | * gusaus has quit (Quit: gusaus) |
| [12:01:41] | * Yaazkal has quit () |
| [12:03:16] | * rominronin has joined #aegir |
| [12:08:15] | * rominronin has quit (Ping timeout: 250 seconds) |
| [12:42:59] | * hosttor has quit (Ping timeout: 276 seconds) |
| [12:44:43] | * inteja_ has joined #aegir |
| [12:55:24] | * Egyptian[Home] has quit (Quit: Leaving.) |
| [13:04:21] | * rominronin has joined #aegir |
| [13:05:18] | * mstenta has quit (Ping timeout: 246 seconds) |
| [13:09:38] | * rominronin has quit (Ping timeout: 276 seconds) |
| [13:32:20] | <jonpugh> | bgm: I've had good experience with backup_migrate and the s3 plugin |
| [13:32:43] | <jonpugh> | You can send backups to s3 very easily, have the client own the bucket, and you're good to go. |
| [14:05:28] | * rominronin has joined #aegir |
| [14:10:33] | * rominronin has quit (Ping timeout: 240 seconds) |
| [15:06:34] | * rominronin has joined #aegir |
| [15:08:37] | * spyd_ has joined #aegir |
| [15:11:20] | * rominronin has quit (Ping timeout: 244 seconds) |
| [15:12:59] | * spyd has quit (Ping timeout: 246 seconds) |
| [15:45:53] | * maestrojed has joined #aegir |
| [16:00:51] | * realityloop has joined #aegir |
| [16:07:41] | * rominronin has joined #aegir |
| [16:13:24] | * rominronin has quit (Ping timeout: 276 seconds) |
| [16:21:07] | * maestrojed has quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
| [16:21:49] | * rominronin has joined #aegir |
| [16:23:14] | * rominronin has quit (Client Quit) |
| [16:36:38] | * realityloop has quit (Quit: Leaving...) |
| [17:09:38] | * ybabel has joined #aegir |
| [17:15:41] | * maestrojed has joined #aegir |
| [17:16:36] | * maestrojed has quit (Client Quit) |
| [17:56:45] | * inteja_ has quit (Ping timeout: 276 seconds) |
| [18:09:17] | * nulp has quit (Ping timeout: 276 seconds) |
| [18:10:46] | * nulp has joined #aegir |
| [18:15:41] | * boshtian has joined #aegir |
| [18:19:06] | * inteja_ has joined #aegir |
| [18:22:45] | * nulp has quit (Ping timeout: 276 seconds) |
| [18:29:26] | * inteja_ has quit (Ping timeout: 276 seconds) |
| [18:44:12] | * mglaman_ has joined #aegir |
| [18:45:43] | * mglaman has quit (Ping timeout: 250 seconds) |
| [18:45:44] | * elijah has quit (Ping timeout: 250 seconds) |
| [18:45:51] | * dean has quit (Ping timeout: 250 seconds) |
| [18:45:52] | * drupol has quit (Ping timeout: 250 seconds) |
| [18:45:56] | * Lowell has quit (Ping timeout: 250 seconds) |
| [18:45:59] | * anto has quit (Ping timeout: 250 seconds) |
| [18:46:09] | * anto has joined #aegir |
| [18:46:43] | * drupol has joined #aegir |
| [18:46:49] | * mglaman_ is now known as mglaman |
| [18:48:04] | * Lowell has joined #aegir |
| [18:49:31] | * nulp has joined #aegir |
| [18:55:17] | * elijah has joined #aegir |
| [19:32:30] | * gandhiano has joined #aegir |
| [20:06:11] | * inteja_ has joined #aegir |
| [20:06:27] | * boshtian has quit (Remote host closed the connection) |
| [20:17:34] | * maestrojed has joined #aegir |
| [20:18:37] | * maestrojed has quit (Client Quit) |
| [20:20:49] | * ceaucari has quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
| [20:21:36] | * rominronin has joined #aegir |
| [20:28:39] | * moshe has quit (Ping timeout: 260 seconds) |
| [20:30:18] | * moshe has joined #aegir |
| [21:00:48] | * inteja_ has quit (Ping timeout: 250 seconds) |
| [21:07:02] | <bgm> | jonpugh: could be interesting when amazon open their data center in canada (soon-ish) :) |
| [21:14:36] | * gandhiano has quit (Ping timeout: 246 seconds) |
| [21:23:08] | * noecc has joined #aegir |
| [21:41:18] | * inteja_ has joined #aegir |
| [21:46:43] | * inteja has joined #aegir |
| [21:48:26] | * a_ok has joined #aegir |
| [21:49:10] | * inteja_ has quit (Ping timeout: 244 seconds) |
| [21:49:48] | <a_ok> | When I upgrade or verify the aegir frontend the owner and group of settings.php get set aegir. How is that supposed to work? |
| [21:53:57] | <a_ok> | I mean in that situation the website crashes because apache(e.g. the mod_php) can't read settings.php. Is www-data supposed to be in the aegir group or something? |
| [21:58:34] | <ergonlogic> | hefring: tell realityloop Let me know if you're still struggling with anything for the RHEL automated install. |
| [21:58:34] | <hefring> | ergonlogic: I'll pass that on when realityloop is around. |
| [22:00:44] | <ergonlogic> | a_ok: no, aegir ought to be in the www-data group though |
| [22:02:55] | <a_ok> | ergonlogic: In the documentation http://community.aegirproject.org/node/77/ I see that settings.php is supposed to be set to aegir:www-data. What did I do wrong? |
| [22:04:39] | <ergonlogic> | that's correct: aegir:www-data |
| [22:04:44] | <ergonlogic> | not sure |
| [22:04:52] | <ergonlogic> | is aegir in the www-data group? |
| [22:05:43] | <ergonlogic> | here's the updated docs, btw: http://docs.aegirproject.org/en/3.x/extend/architecture/#file-system-str... |
| [22:06:47] | <ergonlogic> | a_ok: Aegir ought to set that ownership as part of each verify task |
| [22:07:38] | <ergonlogic> | to fix it, you could chown it aegir:www-data yourself, then run another verify to ensure that it doesn't get reset |
| [22:08:15] | <a_ok> | ergonlogic: yes. groups aegir |
| [22:08:15] | <a_ok> | ->aegir : aegir www-data |
| [22:08:44] | <ergonlogic> | and mode 440? |
| [22:11:04] | <a_ok> | ergonlogic: yeah that seems to be correct. |
| [22:12:16] | <a_ok> | ergonlogic: I just did an update from 2.1 to 2.4 but we had this issue before. As soon as I have the ctools_css_cache table missing error fixed i'm going to upgrade to 3.4 |
| [22:12:35] | <ergonlogic> | good idea |
| [22:13:34] | <ergonlogic> | a_ok: are you using the Debian packages? |
| [22:13:55] | <a_ok> | ergonlogic: No upgrade.sh |
| [22:13:55] | <ergonlogic> | of the upgrade script? |
| [22:13:58] | <ergonlogic> | ok |
| [22:14:47] | <ergonlogic> | let me know how it goes, and if you need any help |
| [22:25:58] | <a_ok> | ergonlogic: We have moved the database to our production database server. Hovever after the upgrate (hostmaster-migrate) it is back on localhost. Is there a way to permanently keep it on our production database server? |
| [22:27:29] | <a_ok> | ergonlogic: Performing a verify still messes up the permissions of settings.php. |
| [22:32:27] | * zombiebeard has joined #aegir |
| [22:39:26] | <ergonlogic> | huh |
| [22:39:47] | <ergonlogic> | a_ok: you should be able to specify a db host during the upgrade |
| [22:40:11] | <ergonlogic> | are you running any contrib extensions |
| [22:40:12] | <ergonlogic> | ? |
| [22:40:19] | <ergonlogic> | perhaps one of them is messing with the perms |
| [22:40:57] | <a_ok> | ergonlogic: Sorry I guess I missed that option will look into it. |
| [22:41:07] | <ergonlogic> | alternatively, if the script/task is failing, it might be leaving the perms incorrect, because it isn't reaching the stage where it chowns/chmods them |
| [22:48:22] | <a_ok> | ergonlogic: No I don't see that happening and there are no contrib extensions. For now I will continue with the upgrade to 3.4 as I have fixed the other issues. |
| [22:54:16] | * mstenta has joined #aegir |
| [23:15:19] | <a_ok> | ergonlogic: I have performed the update to 3.4 however I still see the old drupal 6 frontend. How can I check if the backend was upgraded. Also what version of drush is required? It seems to have created the folder drush-8.0.0 but I am still running 5.10 |
| [23:19:45] | <ergonlogic> | a_ok: try `drush @hm status` |
| [23:21:22] | <ergonlogic> | you'll need at least Drush 6+ |
| [23:21:36] | <ergonlogic> | but 8.x.y is recommended |
| [23:22:12] | <a_ok> | ergonlogic: OK than the upgrade.sh script didn't do anything. Can I do subsequent runs or should I clean stuff up? |
| [23:22:48] | <ergonlogic> | you should be able to re-run it |
| [23:23:04] | <ergonlogic> | is it not providing any warnings/errors? |
| [23:23:08] | <a_ok> | ergonlogic: It did make a new hostmaster-7.x-3.4 platform and did half of the drush upgrade |
| [23:23:31] | <a_ok> | only an error that it could not create a backup. |
| [23:23:52] | <a_ok> | now it gives me a POE exceptions. probably because the database already exists |
| [23:24:26] | <ergonlogic> | could you pastebin the recent log output? |
| [23:27:28] | <a_ok> | ergonlogic: sure working on it |
| [23:49:07] | <a_ok> | ergonlogic: Unfortunatly the drush update seems to fail at the start. I will check if updating that helps |
| [23:51:26] | <ergonlogic> | a_ok: you may need to move the old Drush out of the way |
| [23:56:06] | <a_ok> | ergonlogic: It needs a composer install these day's. Fixed drush retrying. |
| [23:56:22] | <ergonlogic> | a_ok: you're better off using the phar install |
| [23:56:31] | <ergonlogic> | it's just download and symlink |
| [23:56:37] | <ergonlogic> | much simpler to maintain |
| [23:57:17] | <a_ok> | ergonlogic: thanks will replace that and put it in a decent directory. (it's now in bloody /usr/bin) |
| [00:07:31] | <a_ok> | ergonlogic: Still not working |
| [00:07:46] | <ergonlogic> | looking at the pastebin now |
| [00:08:05] | <a_ok> | It now only gives me an error that looks like cleanup required |
| [00:10:54] | <ergonlogic> | "You need to specify an alias or run this command within a drupal site. [error]" ? |
| [00:11:33] | <ergonlogic> | the pastbin looks incomplete |
| [00:11:38] | <ergonlogic> | did it restart apache? |
| [00:12:06] | <ergonlogic> | that might be all that's req'd unless it did a full rollback |
| [00:15:49] | <a_ok> | ergonlogic: nope that was the complete output. Will try to restart apache |
| [00:17:40] | <a_ok> | ergonlogic: didn't work. |
| [00:17:57] | <ergonlogic> | failed to restart? |
| [00:18:19] | <ergonlogic> | you upgraded provision? |
| [00:18:22] | <a_ok> | ergonlogic: Restarts fine. Still old version |
| [00:18:38] | <a_ok> | ergonlogic: how can I check? |
| [00:20:04] | <a_ok> | yep info file has 7.x.3.4 |
| [00:20:32] | <a_ok> | seems the webinterface just isn't migrating |
| [00:21:11] | <a_ok> | ergonlogic: what files do I need to modify? |
| [00:21:38] | <ergonlogic> | you could try running hostmaster-migrate directly |
| [00:28:08] | <a_ok> | ergonlogic: has the exact same result: You need to specify an alias or run this command within a drupal site. |
| [00:28:35] | <ergonlogic> | ok, are you specifying @hostmaster? |
| [00:29:10] | <ergonlogic> | or running it within /var/aegir/hostmaster-6.x-2.4/sites/example.com? |
| [00:30:50] | <a_ok> | drush --makefile=/var/aegir/.drush/provision/aegir.make hostmaster-migrate aegir.example.com /var/aegir/hostmaster-7.x-3.4 |
| [00:31:52] | * hestenet has joined #aegir |
| [00:35:45] | <ergonlogic> | you shouldn't have to specify a makefile, if the platform already exists |
| [00:36:14] | <ergonlogic> | and try adding @hostmaster |
| [00:38:16] | <a_ok> | Just did that. same result. |
| [00:39:12] | <a_ok> | im going to try and manualy change the vhost file |
| [00:51:07] | <a_ok> | ergonlogic: It is not going to work. hostmaster-migrate keeps telling me that it is creating database_1 but I never see it. It is possible that I do not see the roleback? |
| [00:53:50] | <ergonlogic> | I don't knwo why you wouldn't see it |
| [00:54:11] | <ergonlogic> | the database is on the remote db server? |
| [00:54:22] | <ergonlogic> | is there a local mysql-server? |
| [00:54:56] | * rominronin has quit (Remote host closed the connection) |
| [01:06:03] | <a_ok> | ergonlogic: It clean's it up. I can see it when it is importing it. |
| [01:06:19] | <a_ok> | So it encounters an error and reverts |
| [01:06:38] | <a_ok> | I just have no clue where the error is comming from. |
| [01:08:13] | <a_ok> | Is there a way for me to install a clean version of provision (in /var/aegir/.drush)? If I only keep the alias files do I have a clean install? |
| [01:12:34] | <ergonlogic> | yes, that should work |
| [01:14:20] | <ergonlogic> | but if provision was already at 3.4, I'm not sure that another copy of it would make any difference |
| [01:15:04] | <ergonlogic> | perhaps, ensure that the alias for the db server is correct (i.e., has the proper credentials, etc.) |
| [01:15:27] | <ergonlogic> | and that the hostmaster alias, vhost and drushrc.php are also correct |
| [01:16:17] | <ergonlogic> | if there's a problem verifying the hostmaster site to begin with, whatever the root cause is, that's probably causing these issues |
| [01:18:18] | <a_ok> | ergonlogic: Well it definatly did :-) i'm seeing D7 database updates now |
| [01:18:40] | <ergonlogic> | huh, interesting |
| [01:19:03] | <a_ok> | there was probably some broken crap in there that created the error and the roleback |
| [01:24:09] | <ergonlogic> | wel, I'm glad you're making progress |
| [01:27:10] | <a_ok> | ergonlogic: Actually i'm done. Everything seems to be working now. Including the settings.php ownership. |
| [01:27:22] | <ergonlogic> | ok, great! |
| [01:27:33] | <a_ok> | Thank you for the support :-) |
| [01:28:17] | <millenniumtree> | I had a weird issue the other day. We use memcache, and have a snippet in config/includes/global.inc to add a site-specific key prefix... |
| [01:28:46] | <a_ok> | in global.inc? |
| [01:28:46] | <millenniumtree> | We created a site in our 'import' platform (one that closely matches our legacy platform), then migrated to a production platform with module upgrades... |
| [01:29:03] | <millenniumtree> | yeah, global.inc so it gets added to every settings.php file |
| [01:29:42] | <millenniumtree> | Then after the migration, we deleted the site and imported fresh again into the import platform (first time was a dry-run). |
| [01:30:10] | <millenniumtree> | But the second time failed miserably because memcache still had some stuff cached from the same site on the production platform. |
| [01:30:32] | <millenniumtree> | (the cache prefix is generated from the domain) |
| [01:31:38] | <millenniumtree> | So... Where could I place some code to execute on site deletion that would clear out the memcache with the given prefix? |
| [01:32:02] | <millenniumtree> | There's a snippet here to do what I want, but where do I put the code to run on site delete? |
| [01:32:04] | <millenniumtree> | http://stackoverflow.com/questions/10792338/how-to-delete-items-with-sam... |
| [01:32:54] | * inteja has quit (Ping timeout: 246 seconds) |
| [01:33:27] | * ceaucari has joined #aegir |
| [01:33:50] | <millenniumtree> | Here's the memcache snippet from global.inc, BTW. http://pastebin.com/hmftmwbV |
| [01:34:25] | <millenniumtree> | I suppose I could make the prefix unique based on other factors, like platform and database... That might solve this more easily. |
| [01:37:22] | <millenniumtree> | Although if you create a site, delete it, then create it again the same way, the platform and DB would be the same... It'd still be desirable to clear the memcache on delete. |
| [01:39:00] | * a_ok has quit (Quit: Leaving) |
| [01:43:12] | <millenniumtree> | Reviewing the task log for a site delete, I see "Invoking post_hosting_delete_task hooks"... |
| [01:43:19] | <millenniumtree> | Found this: https://www.mikestiv.com/blog/drush-commands-and-hooks |
| [01:43:47] | * gandhiano has joined #aegir |
| [01:46:36] | * TommyCox has joined #aegir |
| [01:51:21] | <millenniumtree> | Is there a list somewhere of the hooks called by hosting operations? |
| [01:52:15] | <millenniumtree> | I'm having trouble understanding what to call a hook to run it on site delete... |
| [01:52:30] | * freiheit has joined #aegir |
| [01:52:30] | <ergonlogic> | millenniumtree: the hooks are automatically generated by Drush, based on the command that's being run |
| [01:52:57] | <ergonlogic> | post_hosting_delete_task would run after the front-end task |
| [01:53:21] | <ergonlogic> | you probably want drush_hook_post_provision_delete() |
| [01:53:43] | <millenniumtree> | "Calling hook drush_db_provision_delete_validate" ? |
| [01:54:05] | * boshtian has joined #aegir |
| [01:54:29] | <ergonlogic> | that'd be before the delete operation, but would presumably also work |
| [01:54:57] | <ergonlogic> | also, you might want to inject that into setting.php directly, for only the site(s) you want |
| [01:55:12] | <ergonlogic> | instead of across the board via global.inc |
| [01:55:58] | <ergonlogic> | this might help: http://api.aegirproject.org/api/Provision/7.x-3.x/search/hook |
| [01:56:08] | <millenniumtree> | I actually want it on all sites. The code does nothing if memcache isn't enabled. |
| [01:56:47] | * freiheit has left #aegir () |
| [01:57:18] | <millenniumtree> | I suppose when we add D8 sites, it'll need some tweaking to support that, but for D6/D7, that works nicely. |
| [01:59:05] | <ergonlogic> | ok, but you'd be able to hardcode the key (rather than use a regex) if you implement: http://api.aegirproject.org/api/Provision/provision.api.php/function/hoo... |
| [01:59:06] | <millenniumtree> | Bingo: http://api.aegirproject.org/api/Provision/db%21delete.provision.inc/func... |
| [02:01:23] | <millenniumtree> | I'd still need the regex to unique it to each site, but yeah, that hook looks cleaner than throwing it into the global. |
| [02:01:43] | <millenniumtree> | Although, changes to global.inc happen immediately. That's both good and bad. ;) |
| [02:01:55] | * maestrojed has joined #aegir |
| [02:03:10] | <millenniumtree> | How would I print to the task log in one of these hooks, to make sure it's running? |
| [02:03:21] | <ergonlogic> | hook_provision_drupal_config passes in the URL and other context, so no, there wouldn't be a need to regex it |
| [02:03:27] | <ergonlogic> | drush_log() |
| [02:03:49] | <millenniumtree> | Ahh, super. |
| [02:04:15] | * boshtian has quit (Ping timeout: 276 seconds) |
| [02:04:18] | <ergonlogic> | also, since you'll need a drush extension to keep you delete hook code, moving to hook_provision_drupal_config() would allow you to keep that config together |
| [02:05:54] | <ergonlogic> | also the dynamic regex may cause issues if you access a site via an alias, for example |
| [02:08:22] | <millenniumtree> | $_SERVER['HTTP_HOST'] is the default/primary domain. But yeah, I see what you mean. Far more elegant in the hook. |
| [02:09:36] | <ergonlogic> | right, I'm not suggesting that it wouldn't work, just that it'd potentially be more brittle |
| [02:12:13] | <millenniumtree> | I've been hacking on Drupal stuff for years, but just getting into aegir and drush hooks. This helps immensely. |
| [02:12:18] | <ergonlogic> | fwiw, I generally only use global.inc for setting things like php memory limits and such |
| [02:14:05] | <ergonlogic> | another nice thing about using drush hooks, is that Hosting Features can now ship with provision extensions, making it possible to update/deploy them via a makefile for the Aegir front-end |
| [02:14:19] | <ergonlogic> | that requires more boilerplate |
| [02:14:19] | <millenniumtree> | I set those in the php.inc. :P |
| [02:14:57] | <ergonlogic> | ok, then `@define('CIVICRM_GETTEXT_NATIVE', 1);` :p |
| [02:15:38] | <millenniumtree> | right on. |
| [02:15:47] | <millenniumtree> | (I hate Civi) |
| [02:17:57] | <ergonlogic> | fwiw, I've been working on improving our testing, so that we can eventually move to gitlab. The upshot of that will be that you could ship a small makefile that'd add a custom module that could contain any Aegir workflow customizations. And *that'd* then be easily testable too |
| [02:18:38] | <ergonlogic> | still a ways off, but the groundwork is coming along nicely |
| [02:19:43] | <millenniumtree> | I actually now think the memcache clear-on-site-delete isn't necessary. I can always restart memcache if it happens (might happen to us once a year)... But the hook for the memcache settings makes that way more easily deployable. w00t! |
| [02:21:00] | <millenniumtree> | Yeah, the automated testing platform is fabulous. |
| [02:22:01] | <ergonlogic> | I've been working on some Ansibl roles to support that: https://galaxy.ansible.com/ergonlogic/ |
| [02:22:19] | <ergonlogic> | one challenge we've had is being able to effectively test multi-server scenarios |
| [02:22:50] | <millenniumtree> | JUST getting into ansible. No time to study it at the moment, but it could help us a lot as we get more servers. |
| [02:22:56] | <ergonlogic> | the cloud role should allow us to easily spin up a whole cluster of servers, and configure them all |
| [02:23:20] | <millenniumtree> | sounds epic |
| [02:23:22] | <ergonlogic> | so that we'd be able to test things like remote_import, web_clusters, etc. |
| [02:23:45] | <ergonlogic> | long road ahead, but I hope so |
| [02:23:56] | <millenniumtree> | Yeah, I initially thought creating a single hostmaster with spoke servers would be a good idea, but I put the hostmaster on smallish SSD. |
| [02:24:15] | <millenniumtree> | The backups and site files were all being stored on the hostmaster though... |
| [02:24:16] | <ergonlogic> | filled up with backups? |
| [02:24:23] | <ergonlogic> | right |
| [02:24:26] | <millenniumtree> | :) |
| [02:24:47] | <millenniumtree> | So now the SSD is just purely our database server, with other VPSs pointed to it. |
| [02:24:48] | <ergonlogic> | I hope to have some time to work on hosting_s3, to help resolve some of that |
| [02:25:34] | <ergonlogic> | one of the reasons for launching the Aegir Co-op is to help finance that kind of work |
| [02:25:39] | <millenniumtree> | And since I figured out remote import, multiple hostmasters isn't really a problem now. |
| [02:25:43] | <ergonlogic> | especially the testing/maintenance |
| [02:26:27] | <millenniumtree> | And memcache helps reduce DB cache traffic, so that's why it's enabled on every site. :) |
| [02:26:30] | <ergonlogic> | there's been a lot of work done on 'sync' tasks that could help in similar scenarios |
| [02:26:48] | <millenniumtree> | Yeah. Heard about those, but haven't gone in-depth yet. |
| [02:26:54] | <ergonlogic> | you might want to check out apdqc/mysqlnd too |
| [02:27:17] | <ergonlogic> | I've seen a huge performance boost from those |
| [02:27:22] | <millenniumtree> | using mariadb right now |
| [02:28:08] | <ergonlogic> | I'm pretty sure that mysqlnd works with mariadb |
| [02:28:36] | <ergonlogic> | or maybe you're already using it |
| [02:28:53] | <millenniumtree> | using php 5.4, so mysqlnd should be compiled in... Hmm |
| [02:28:58] | <ergonlogic> | in which case apdqc.module would be pretty easy to deploy |
| [02:29:40] | <ergonlogic> | I have seen some weirdness with the php opcache and mysqlnd though |
| [02:30:18] | <ergonlogic> | iirc, I had to disable the opcache, because it was throwing kernel panics |
| [02:30:19] | <millenniumtree> | we use apc and php5-fpm if that makes any difference |
| [02:30:25] | <ergonlogic> | still saw a performance boost |
| [02:30:59] | <ergonlogic> | I think apc was replaced with the native opcache in 5.5 |
| [02:31:10] | <millenniumtree> | IC |
| [02:31:12] | <ergonlogic> | but I don't recall the details off-hand |
| [02:31:36] | <millenniumtree> | adding apc was night and day - dramatically faster. |
| [02:31:45] | <millenniumtree> | And the php realpath cache. :P |
| [02:32:44] | <millenniumtree> | Since we use memcache for pretty much everything, would apdqc help us much? |
| [02:34:02] | <millenniumtree> | Just checked because I was curious and our APC hit rate is 96.2%. :) |
| [02:38:48] | <millenniumtree> | Hmm... I'm curious how memcache compares to apdqc w/o memcache... The prefetching is interesting. |
| [02:39:12] | <millenniumtree> | We have dblog turned off on all our sites anyway to reduce DB writes (use syslog instead). |
| [02:39:49] | <millenniumtree> | Our largest platform is all D6, so it's a bit of a moot point there, but for our other server, it could be advantageous. |
| [02:51:21] | * Yaazkal has joined #aegir |
| [02:55:24] | * rominronin has joined #aegir |
| [03:00:35] | * ybabel has quit (Remote host closed the connection) |
| [03:00:56] | * TommyCox has quit (Remote host closed the connection) |
| [03:02:17] | * rominronin has quit (Ping timeout: 276 seconds) |
| [03:04:09] | * gandhiano has quit (Ping timeout: 260 seconds) |
| [03:07:57] | * cmoates has quit (Ping timeout: 276 seconds) |
| [03:09:12] | * cmoates has joined #aegir |
| [03:27:15] | * TommyCox has joined #aegir |
| [03:46:36] | * TommyCox has quit (Remote host closed the connection) |
| [03:47:11] | * TommyCox has joined #aegir |
| [03:51:46] | * TommyCox has quit (Ping timeout: 252 seconds) |
| [04:33:29] | * gusaus has joined #aegir |
| [04:56:48] | * rominronin has joined #aegir |
| [05:02:32] | * rominronin has quit (Ping timeout: 276 seconds) |
| [05:32:50] | * noecc has left #aegir ("pax") |
| [05:45:28] | * TommyCox has joined #aegir |
| [05:57:53] | * rominronin has joined #aegir |
| [06:03:13] | * rominronin has quit (Ping timeout: 252 seconds) |
| [06:37:34] | * Yaazkal has quit () |
| [06:59:00] | * rominronin has joined #aegir |
| [06:59:16] | <ergonlogic> | helmo colan fyi, Debian-package-only releases should be possible with the next release of Drush |
| [07:04:03] | * rominronin has quit (Ping timeout: 240 seconds) |
| [07:17:03] | * freiheit has joined #aegir |
| [07:59:48] | * zombiebeard has quit (Quit: zombiebeard) |
| [08:00:05] | * rominronin has joined #aegir |
| [08:05:03] | * rominronin has quit (Ping timeout: 240 seconds) |
| [08:43:07] | * TommyCox has quit (Remote host closed the connection) |
| [08:46:33] | * hestenet has quit (Remote host closed the connection) |
| [08:51:33] | * michiel has quit (Ping timeout: 240 seconds) |
| [08:53:33] | * michiel has joined #aegir |
| [09:01:11] | * rominronin has joined #aegir |
| [09:06:22] | * rominronin has quit (Ping timeout: 252 seconds) |
| [09:26:53] | * inteja has joined #aegir |
| [09:38:14] | * Egyptian[Home] has joined #aegir |
| [09:54:05] | * hestenet has joined #aegir |
| [09:54:44] | * maestrojed has quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
