University Shares Tips for Migrating Thousands of Sites With One Install Profile [December 5, 2012]
University Shares Tips for Migrating Thousands of Sites With One Install Profile [December 5, 2012]
Want to learn more about Acquia’s products, services, and happenings in the Drupal Community? Visit our site: http://bit.ly/yLaHO5.
The University of Waterloo has spun up more than 150 websites using a single Drupal 7 installation profile. And they plan to migrate more than 1,000 sites using this approach. Tyler Struyk of the university’s Drupal Implementation Team will explain the details of this process, as well as lessons learned.
In this webinar, you will learn:
• The migration process used by the university
• How to keep everything in sync while rolling out new features or bug fixes
• Development recommendations from the implementation team
• Tips and Tricks learned along the way
Female: Thanks for joining today. Today’s webinar is University Shares Tips for Migrating Thousands of Sites with One Installation Profile with Tyler Struyk who’s the Drupal Developer at the University of Waterloo and was on the Drupal Implementation Team there.
Tyler Struyk: Today I’m presenting on what I’ve been doing last six months at the University of Waterloo and what they’ve been doing for the last three years.
A little bit about myself. A lot of people know me as iStryker on drupal.org. I’ve been using Drupal since 2007. Most of that time, I’ve been working as a freelancer and then as I said, I’ve been working at University of Waterloo fulltime for the last six months.
We actually have quite a few websites. Our site here … the two things I wanted you to note is the uwaterloo.ca and pilots.uwaterloo.ca. The uwaterloo.ca are actually the number of websites that are live currently and the Pilots are the websites that are currently in migration to be put into production.
A little bit of history. Certainly, the University of Waterloo, what they used to do was they usually use Dreamweaver templates to give a common look and feel for all their websites. Now, this was quite a bit up trouble because if they ever need and make a change to the website, they will have to push the new template up to uwaterloo.ca and then everyone who owned the website would have to pull that new template down and then push it up to their own existing website. This whole process might take sometimes quite a few months for all the changes to be the same across all the websites on campus.
After that, I think three years ago, right after DrupalCon San Francisco, the University of Waterloo started moving to Drupal and what they started doing was creating one of Drupal 6 websites. This was fine, this was great, the only problem is there’s no way to keep track a lot of them. Sometimes if you had a new feature, you could push out to one or two, but once we eclipsed 25 websites, it was very hard to maintain them all.
Here at University of Waterloo, what we actually call our website is the uWaterloo Content Management System. It’s one installed profile. At least in production, all the websites are on one server. It’s used by all Faculties across the campus and they are all running the same features for the most part. Some websites have one or two one of customization modules, but overall, they all have the same modules and features.
Now, here is an example of the environment websites what looks like right now. This is actually our homepage. Our homepage is a little special. It’s running on Drupal. We actually relaunched this website back in August, end of August. It has the same features and modules, et cetera, but it’s a little trimmed down. It doesn’t need as much features as the Content Management System running on for the other websites. As you see, the website is running a different theme. That’s the most main difference is this running a different theme.
Here at University of Waterloo, there’s actually 15 or less. We have eight people doing the Content Migration and Training. We have five actually doing the actual development and pushing on new features and doing the bulks. We actually have one guy pretty much devoted to accessibility. Now, here at University of Waterloo, the government has come down with an accessibility guideline that we have to meet. Every public sector website must be accessible and this is going to be pushed … I think the standards that we have to meet is coming out in 2014. We’re getting a little ahead of ourselves, but yes, every new piece of content that we have have to meet these goals. Then we actually have a system administrator who does all the backend stuff for our website. I’ll get more into detail what he actually does near the end of the presentation.
As I said, there’s eight people working on the Content Migration and Training. It’s actually broken into two groups. We have two fulltime employees and they work on everything like the migrations, save the migration meetings, doing Q&A, training, support and communication. Now, here at University of Waterloo, we are the school that’s known for co-ops. Nine percent of our courses here at University of Waterloo have a co-op component to it and I don’t know if people on the states around the world know what co-ops mean. You might think of it as internships. Every four months, there’s new co-ops to come in and we actually break the six co-ops in two different groups. Four of them are doing Content Migration and we have them … each one of them is doing a separate site at a time and then we have two of them doing the Q&A and drop in labs. I’ll talk more about the drop in labs in a couple of slides.
The process of migration. If you want your website on campus to be migrated to the new Content Management System, you first put a request. Here at University of Waterloo, we’re using the Request Tracker System. I don’t know if you guys know that. That’s what it matter. After that we request in, we set up a review meeting. We go over the requirements needed. It’s pretty much that. You train and also determine if they’re a good candidate to actually move in the system.
Now, sometimes, there’s websites out there that are not good candidates and a good example of that is the athletics. They have quite a bit of customization and they might probably get into our new Content Management System once we roll out more features, but this is probably in a couple years time down the road, just a list of couple of customizations that you have e-commerce components selling tickets. They have custom content types for sports and teams. They keep track of sport scores. They have advertisement, sponsorship and as you see on the page here, they have a custom layout.
Now, after this meeting, we actually create a website for them to start the migration and we created on the pilots.uwaterloo.ca. We actually assigned a co-op student to help them out. Now, this co-op student might do everything for them and might do the whole migration process of covering the content from their old websites to their new websites or they might just do a small portion and that’s the person who owns the actual content and do it themselves. We set the launch dates. For simple websites, the launch date might be two weeks away, but for complicated websites, they might be a couple of months away. Ten days before, we actually launch the site. We do a lot of Q&A and the one tool that I want to mention is we actually run the Wave Accessibility Test. The WAVE is custom two variation into Firefox and it analyzes your page and tells you what’s … if you have any problems, asystic problems with your current website.
Here at University of Waterloo, we have quite a bit training to support the whole Content Management System. Some of these courses are mandatory. If you have want to maintain the content on your site, you have to take the Content Maintainer Course and then there’s a more advanced reason, which is the Site Manager’s Course. The difference between the two Content Maintainer’s Course is basic Content Maintainer so that you can create new contents, review contents, create new drafts, add new images, things like that. Site Manager’s Course is pretty much like changing layout maybe, just more advanced things. The other course we have is webforms. If you actually want a webform on your website, you have to take the Webform Course. The reason why we force to do this is there’s a lot of things you can do with webforms such as credit card information, et cetera. For privacy reasons, this is the reason why we make them take this course.
Then, there’s a variety of additional tools. Twice a week, there’s a drop in lab so it’s ran all-day. If you have let’s say you have questions, you come in and ask. Once a month, we have a developer’s drop in lab so the five people that do the bug and testing, you can actually ask them to them more advanced questions and have one-on-one time with them. We also do quite a few training videos. I’d like to mention that I actually use Camtasia Studio 7 to do the recordings, but I recommend using version 8 to do it. As version 8, you can have a lot more multiple layers, where Camtasia 7, you can only do one or two layers. An example of that is here. I just pulled this off a website. It just gives you basic idea of what it looks like and the tools you have.
Now, there’s other courses we offer like advanced forms. There’s quite a few tools that you can do with advanced forms, more advanced stuff like regular expressions, filtering and there’s other supporting courses like … that you’ll need to take such as writing for the web and writing accessible content.
The other thing the Content Migration Team does is communication and there’s lot of ways they do this. We have multiple mailing list set up to the reach different departments and we also have the web resource website. On this website, we communicate everything, the upcoming courses, new features, common things like what colors you should be using. If you’re a part of … here at University of Waterloo, each faculty has their own colors and you can come to this website and say, “Hey, what color shall I be using for my faculty?” There’s also accessibility tips and we also push out new news such as term reminders such as on your website, take down your co-op students, et cetera, because quite a few people actually forget to do this.
Back in November last year, we actually pushed out version 1.0. Since then, we are at version 1.5.8. The changes within these two are such things as live streaming, a better slideshow integration and there’s quite a few more tools that have changed between that version and this version.
Websites and servers, these two websites we actually use. One is Request Tracker I mentioned and we use this for bug tracking. We also have this in-house agile project management website that we used for people to press new features and I’ll talk about this later on in a couple of slides. We actually have quite a few servers here that we use for development and testing. I’ll actually switch the next slide to give you a better diagram.
For testing, I kind of want to go to each one of these and the reason why we actually use each one for different scenarios. For your Local Dev, we usually have a standard installed profile on there, just plain Drupal or Drupal 7 or maybe in your case Drupal 6. If there’s a new bug, we test to see … it’s like against Drupal to see if it’s actually Drupal that’s broken or it’s actually our installed profile that’s broken. We also do a lot of Local testing locally. If you’re working on something, you’re going to break something huge, but it’s going to cross the server so you can test out little clear.
Now, we have a web server, the Sandbox and the version of the profile on there is actually the trunk version so any new changes that you push gets pushed up there nightly and gets rebuild. If you want to do testing on what’s upcoming, that’s where you do testing on. Now we have Dev, which is the current release that’s on production. It’s on Dev. If you want to test something or … it’s mostly for bugs. If you want bugs, bug testing, this is where you go to test. It’s pretty self-explanatory.
At first, we just only have one server, the separate Sandbox to production, but it’s broken into two different ones. We introduced the profile server. On here we actually … it’s identical to the Dev server, but we use this specifically to test other installed profiles such as Commerce Kickstart and CiviCRM. The reason why we do this is this installed profiles can break a lot of things and we kind of … having two servers, it’s either to troubleshoot what the actual problem. Is it the actual profiles, other extra modules installed on the server or it’s our installed profile that’s the problem.
Then we have two different servers. As I mentioned before, Pilots and Production and these are two servers that we don’t touch for testing. We do have one exception though. On production, we have a test website and the reason why we use this is because on production, there’s a lot of exterior components I guess that you won’t see on the server such as caching. We use various caching pretty instantly here at University of Waterloo and we can’t mimic that while on the other servers so if we need testing, we will actually push in production and test it there. There’s two things moving forward that would probably going to change. On Sandbox, we were actually probably going to switch over to Jenkins and by switching over Jenkins, what will happen is … so pushing changes once a day up there, they rebuild once a day, but we can rebuild the server let’s say every five minutes.
For production, we actually want to start using Vagrant and what Vagrant is good for is … I’m just reading the questions here. I’m going to get that effect. What Vagrant is good for is you can copy what the settings are for production instead of multiple virtual servers so you can actually set up a virtual server for caching and production and then we can do the testing on there. That way, we will not have to touch production at all in the future.
Someone asked are we actually using Aegir? We are not using Aegir at all. For development to push to create websites, there’s too many bugs and we weren’t able to use this efficiently. Then, do we use Drush? Yes, we use Drush extensively and I’ll kind of get more into detail of the Drush later on in a couple of slides when I’ll show you how we actually push and then release out.
Typical bug fix, I’ll just quickly go over this. Someone creates a ticket in RT and then the Implementation Team works it Local again, standard profile, things that are breaks, Sandbox, trunk, testing in trunk and Dev and Profiles for the current release that’s currently in production. Now, if a bug is breaking production well, then we’ll roll a new version right away. If it’s not urgent, then we’ll commit it to trunk and then roll it out in the next release.
Our installed profile is actually pretty simple. It’s actually made up of four … I think it’s five files and so you got the .profile, the .install and the .make file. The .make file, I don’t know if you guys know. The .make file lets you pulls down all the modules, themes, everything from our repository and it kind of looks like this. All you have to remember, if you don’t know what a make file is, it’s just a grocery list. It says grabs or theme pulls it down.
When you’re committing trunk, there’s two things you got or make in commit. There’s two things that you’ve got to do. You have to commit the trunk and it just create a new tagged version. When you’re creating a new tagged version, we use an increment system so whatever the current version, that’s that in production. An example down here, you see 1.24. If that’s in production, then you create increments such as 1.24.1 and et cetera. The other thing I want to point out, when you’re re-rolling a new feature, the one problem we found is that our features actually are not just configuration.
Creating a new release, as I kind of mentions before, every increments, we kind of increase it so as I saw 1.24.2, we increment this to 1.25. It’s pretty self-explanatory. Sometimes in creating new release, it takes quite a bit of time because sometimes you’re doing a lot of increment decisions so you might be incrementing quite a few times, testing it and employing back down, other times, this is quick fix and you push up. I’ll kind of touch that more later on.
I’ll kind of get to couple of questions here. Someone asked if we’re using Git. No, we’re not using Git right now. We do want to move to it. Currently, we’re using SVN, but yes, in the next month or so, we’re going to move to Git. How many themes are you running in your installed profile? We are currently using one theme minus the homepage, which is using their own theme. How often do you add new features to production sites? Pretty regularly, we add … as for new features, maybe every release, we add it with one or two features.
As for making changes to the current features, we actually make quite a few changes. Between feature releases, you might be updating 10 features. How many features do we currently have? We have quite extensive list of features. I believe … I don’t know the number off the top of my head, but we have over 50 features broken down to different components. Then the other question was set up as a multi site. The answer is yes and I’ll kind of show you an example of that indirectly later on.
Okay, so here’s an example of pushing out a new release. Now, it’s not every time … when you push out a new release, sometimes things run smooth and majority of time, they don’t run smooth. You do all these works. You usually on a Sandbox, you had the trunk version. The trunk version, you take and then you push this to Dev and Profiles for testing. You test this on the sites that are on Dev and Profile. It could be … I think there’s like 20 odd websites on there right now. If these sites don’t break, then you push off to Pilots.
Usually on Pilots is … at any given time, 60 websites so then you’re testing those websites to see and if it breaks anything, everything is running smoothly or not. If something breaks on Pilots, then you might pull it down to Dev or Profile to testing again on them and it pushed up the Pilots, the next release of two Pilots or if something is really huge, you might have to pull it down with … right down to Local and test it there.
How we actually push it up from Dev, Profiles to Pilots then Production, we actually have Drush scripts that we actually build ourselves. It’s actually pretty simple. You run the make file, you pull everything down, you run DB updates so you update the database and then you feature for everything.
As my notes, so when we’re creating new releases, sometimes it create data releases and sometimes we create release candidates. It’s the same thing you do on drupal.org with modules, we might get the same thing.
Someone asked here are we currently running on Drupal 6. We are actually running on Drupal 7. Everything is Drupal 7.
I actually kind of touch this earlier. I forgot that I had a slide on this. The installed profile … here’s all the files that are part of it so .info, .install, .profile, .make and then we actually have this rebuild.sh, which is a script. Every time you pull down the repository, you actually run the rebuild script and delete the entire profile and then runs the .make file and pulls everything back down. Then we actually have a special server and on that, I think back in the slide number one, I think I should jump there. We had a server called wms-aux.uwaterloo.ca and you see there’s only two there.
On this server, we actually have a custom script that we use Drush for it or server, which have a custom drip Drush command that we run that creates a website for us. We can actually specify a lot of different parameters to it so we can specify which installed profile to use, or which server to install that new website on. When we do that, it creates all the files that you need. It generates the database on our database server and then proof, we have a website up and running. The details of the script, I can’t tell you. I don’t really know. That’s our system administrator. He did this. He spent I think quite a few months building the script, perfecting it, tweaking it, et cetera.
I shall answer a couple of questions before I jump to next topic. Actually, the question that are coming in right now, I’m going to leave to the end.
I’ll talk a little bit about the Agile Project Management Website, this is a website that we use to take out a new feature request that people want to see in our Content Management System. I’m not going to … I’m going to quickly go over the Agile process. I could do a full presentation on what Agile is and how to run this successful Agile sprints, system, et cetera. I’ll just touch base on the topics. People make feature request. This feature request that come in, we turn them into user stories and then we do sprints on those user stories. If you make a feature request, you can become a stakeholder of that user story. In our system, we rank.
As a stakeholder, you can be … well, as a person, you can be a stakeholder of multiple issues and you have to rank the issues that are most important to you using a drag and drop module. The module I have that I custom made is actually on drupal.org. It’s called User Priority Ranking. If you also become a stakeholder, you also can … if you don’t want to become a stakeholder, you can follow us and then … this email communication so if anyone creates a new comment on a user story and you will get an update on the current status of it.
Here’s the ranking system. There’s the module. We use a system I’ll come and reiterate. We use this too as a point system. If you’re rank number one, you get 10 points, if you’re rank number two, you get 9 points and so on. Then, based on our points users, this gives us an idea of what people actually wants and then these are the feature request of user stories that we work on first.
Why do we actually use our Agile Management websites? It’s actually the only way to keep yourself sane. At first, it wasn’t … we didn’t actually need to use it that much because we only had a few websites in the Content Management System. Once you actually get to … once your number hits … well at least for us, once our numbers hit over a hundred, we felt that we became a kind of like … I mean it’s only … or the development team became like “maintenance only” so instead of working on new features, we are working on bugs. It just … new features just came to halt and that was a bad idea so by using the Agile process, people can see, people can track the new features so you know when they are going to be rolled out and this helps the development team keep on schedule and keep its sanity.
Now, we’ll talk about the System Administration. I shall look at the questions first right here before I jump to next one. Now, the questions … I’ll leave the questions that came in to the end.
All right, so how we have it set up is that if you go to uwaterloo.ca, that’s one website. If you go to uwaterloo.ca/physics, that’s a different website and things like /environment, /chemistry, these are all separate websites that are running on the same domain.
Now, there’s two ways to control how this works. One is to do some bulk links and the other way is to use Apache. We actually chose Method number two and I’ll kind of go into detail why we did this. The main reason is because symbolic links actually make are re-directive very messy and it’s … yes, I don’t really … yes, this pretty much it.
Apache includes a directory and in this directory, there’s a special configuration file for each website such as you see there for one for environment like applied-health-science. What they do is you come … a pilot come … went over this already. If you go to let’s say uwaterloo.ca/about, that goes back to uwaterloo.ca/. If you go to uwaterloo.ca/environment/about, well, it points, it doesn’t redirect … goes to the environment website and pulls the content from it and from that database. Then you can go to an additional level degree such as ecology, which is under environments and you can kind of see on the slideshow the structure we have there for our files.
Now, here at University of Waterloo, we use three types of servers, Pound, Varnish and Apache. This is a little different from how other people set up. It’s very common to have Apache and Varnish. If you guys don’t know, Varnish is a front in caching so that the Apache server doesn’t get hit too much. If you’re having questions about Varnish, I recommend that you look it up.
We use Pound for a couple of reasons. One of the main reasons we use it for is to transition HTTPS to HTTP and then this way, you can cache stuff. Here at University of Waterloo, what we want to do is actually have all the websites switched over to HTTPS and to do this, this is the only way to do this is to have Pound in front so that stuff doesn’t go straight to Varnish. It stops at Varnish and then serves up … it serves up caches if it can. I kind of went over the details about this already. In fact, Varnish does not handle HTTP access that well and the reason why the strips the headers off.
Now, the other one problem we have is we always … like you see Dreamweaver websites here at University of Waterloo and we … to grab it Dreamweaver templates for these other websites. They actually go to uwaterloo.ca/css and grab the CSS files as well as /images to grab all the image files. Now, before uwaterloo.ca was a Drupal website, before it was, this was no problem and this was easy for the system as a shredder to handle, but since uwaterloo.ca became a Drupal website, what happens is when you hit that link, Drupal wants to take over and do its own thing. We actually use Pound to revert around this process so if you actually hit our system, uwaterloo.ca/css, Pound actually serves up these style-sheets to you instead of actually hitting the Drupal website. This is very important, like I said, there is over 800 websites out there that are currently used in the Dreamweaver templates that are clearly not migrated to the new system.
One of the other problems we have is with redirects. How the current system works is if you’re not in the … our new web Content Management System, you have your own sub domain. When you come into our new system, sometimes, when you migrate over, you have content … you can’t migrate into our new system and what you need to do is have … redirect to the old system. Sometimes, you might list off on your own that never gets migrated to the new site for quite a successful time or the things too that happens is … you see a one to … how do you explain this? You need a one-to-one mapping of the old content to the new content. This might be like a straight … page one to page one or might be some funny name to a good Drupal website name.
How do we actually handle this is that we actually have a single file that Apache looks at and it just goes through and it goes, “Okay, you hit this page, okay, great then you need to grab this page.” It’s just a one-on-one sequential looking file.
The other thing that … when you have these many websites that becomes unmanageable is these things, a .php file that exist and what we actually done was actually we broke this out into multi different components. Now, I’ll show you an example here. The image on top is actually what the settings .php file is for each individual websites. As you see, it’s only eight lines there. What it does, it pulls in other sending from additional files that are usually pretty static. Right there it pulls up some of the files you down below, it holds some … the standard database settings and then it pulls in the other files that have other settings such as … as you kind of see in the screen now.
There’s special settings at .php file for the database, the host, the network and the settings. If you ever change the domain for your database, you only have to change one file and poof, every other website works. The same if you change the IP address, poof, they’re like … you change one file and then it gets pushed out to all the other websites out there
All right, so what’s coming up. Here at University of Waterloo, we’re going to work on Proper High Availability and we actually want to look at Net App Files for storage as well as my HTML, putting out multiple servers to handle this. The other thing we want to look into is Nginx and this might be able to replace the system we have now with the Pound, Varnish and Apache. The one thing holding us back for that is the Nginx module we write or we write module. Sorry, how is this?
How Nginx handles URL rewrites is quite differently different than what Apache does. Apache has quite a standard control of the things you can do, where Nginx has a smaller slim down version and it can’t do as much. Switch over will take some work this two … it’s on like a one-to-one switch over. It’ll take some time. I should actually state like I’m not a system administrator here at University of Waterloo so some of the stuff I’m just mentioning now is a little over my head, but I kind of want to give you an overview of some problems that I actually have. As I said, I mentioned before, we actually want to switch over to HTTPS for all the websites. We’re currently not doing that over now, but in the next few months, we will be switching over through that.
The other thing I want to talk to you is … this is kind of a little off topic, but how we actually handle search here at University of Waterloo, we actually purchase a Search Engine Appliance from Google that … it’s a server by itself, it does exactly everything that Google does, but it just indexes your own websites. We actually have a thousand websites and that indexes everything for us so it had a little search. You can do the same thing like using Apache Solr, which is an open source projects. We just decided to go with the Search Engine Appliance because it did all this out of the box with very little configuration and comparing to cost, I think when we set up the Search Engine Appliance, it cost us like $50,000 for each one. We’re going to purchase probably the second one and it cost $50,000 for … to use that server for two years and we felt that was good, the better way to go instead of hiring/contracting out someone to set up Apache Solr for us.
The other thing too moving into the future, we actually want to segment our content, how it shows up in their search engine. For example, google.com right now, they have different sections so they have a section for videos, they have section for images, like that, but we have different sections and the Google Search Appliance is set up so that we can set this up for custom content for ourselves. We can have a special tab in search for just events or one for news or videos and podcasts. It’s very easy to set up to all these things with little System Administration support. Whereas with the Apache Solr, there’s quite a bit more support you need to set that all up.
Here’s a question here. What does the question say … someone asked how do we interface the GSA with the Drupal websites and one actually asked someone in fact to … my boss here and I’ll get him to answer the question for you and again, in a sec. We’re about almost done here. Just a couple of notes, we actually don’t have any e-commerce integration with our Content Management System. The reason why we don’t or one of the reasons why we don’t is for … here at University of Waterloo, we have strict policy, we don’t want to get sued by people … like handling credit cards and things like that.
We actually have a special server set up just to handle e-commerce and this is the servers behind strict firewalls and et cetera and right now, we don’t have a need to set up e-commerce. If you want to set up e-commerce, then you will have to set up yourself. You can actually set up your own Drupal website, install Drupal e-commerce, but you won’t be part of the Content Management System. We won’t be giving you support for that.
All right, so that’s what I have. That’s all the slides that I want to go through. I can take any questions you have now.
Female: Hi everyone, if you have any questions, please ask them in the Q&A tab.
All right, we have a few coming in. The first one is how to update multiple databases for multi sites?
Tyler: Currently, we actually have only one … I could be wrong. I think we only have one database and yes, we have only database. It’s segmented. Each website is … sorry, we only have one database server … well, we have two servers. We have one that’s backup and one is our primary one. On this database server, every website has its own database. There you go.
Female: Okay, great. Are your set up as a master slave?
Female: Okay, great. The next one is, for approximately 60 websites, are they all the same domain or are they running different domains?
Tyler: Sorry, the 60 websites? The …
Female: It must have been on your I think slide three is what they were referring that. I’m not sure.
Tyler: Oh yes. Are you referring to the Pilots? The Pilots itself here. If you were referring to the Pilots, the Pilots is running identical to the uwaterloo.ca, the set up so they’re all on the same domain.
Female: Okay, great. How do you open a new site? What is the procedure?
Tyler: Okay, so this is a little of my end. I know we have a custom script that goes in and creates the file system for us, creates the database for us and pulls down all the modules of the file that you need from the .make file. That’s inside the installed profile.
Female: Okay, great. The next one is, how many centers do you have running all your courses and what department do they belong to?
Tyler: How many courses? We actually don’t have any courses online. It’s not part of our Content Management System. It’s just content itself.
Female: Okay, great. The next one is, what Agile Project Management tool are you using?
Tyler: So far … we’re actually … as I mentioned, we are in our own in-house built Agile sites doing to all … to do to handle everything.
Female: Okay, we’re currently using a contextual home group portal system that serves about 250 different differences at our university. Is Drupal well suited to create a similar system?
Tyler: I didn’t quite understand it. Contextual?
Female: We can move on to the next question if that person will clarify.
Tyler: I can just mention that like … the current system we have now … so we have 178 websites moving forward over the next two to three years, you’ll see that the number grow substantially so we have over 1,000 websites here at University of Waterloo and the next three or four years, that number will jump to probably 500 plus. Right now, we think our current system will be able to handle that no problem.
Female: I believe the next question wants you to show the Apache config shot for your Vhost again.
Tyler: Okay, this is the slide. You have to be … I kind of went … this is an overview of everything. To understand all this, you might be more … this site is more geared to a system administrator. You have to look at this right away and go, “Oh, I get that.”
Female: Okay, our last question is, have you looked into Squid cache system, if so, what is your opinion?
Tyler: No, we have not look at all. To tell you the truth, I don’t know what that is.
Female: Okay, great. Thank you Tyler. Thank you for the great presentation and thanks everyone for your questions and attending today. Again, the class …
Tyler Struyk: They talk to my boss and that one question the person had about the search, I can answer that.
Female: Okay, great.
Tyler: For the search, currently, we are sending everyone to uwaterloo.ca/search, which is a custom theme sites that look at down to our Content Management System, but that’s just the sever itself. Once we switched over to version 7 or GSA, then we’ll be able to pull in the contents right into Drupal. For now, we’re just going … sending them to the actual server to display the information to them.
Female: Okay, great. Now, I think that’s it for questions. Again, thank you Tyler and the slides and recording of the webinar, we posted to the acquia.com website in the next 48 hours. Thanks everyone.
Tyler: Thanks everyone.