Closed Bug 547041 Opened 15 years ago Closed 15 years ago

Build www.drumbeat.org production server

Categories

(mozilla.org Graveyard :: Server Operations, task)

Product:
mozilla.org Graveyard
Component:
Server Operations
Type:
task
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: gerv, Assigned: oremj)

Details

Please build a production server for www.drumbeat.org. The database will be transferred from the staging server drumbeat.stage.mozilla.com. Please ping Mattzilla (Matt Thompson) on IRC before taking this step. Our annotated version of the install instructions are here: https://wiki.mozilla.org/Drumbeat/Website/Install Any clarifications and updates you have would be most welcome :-) As soon as you know what it will be, please tell us the IP address of the machine so we can get DNS set up. Also, we will need to know how mail sending is configured, so we can get the MX records right. Gerv
(In reply to comment #0) > As soon as you know what it will be, please tell us the IP address of the > machine so we can get DNS set up. Also, we will need to know how mail sending > is configured, so we can get the MX records right. Uh, why not just transfer the domain to Mozilla? ... or if that's not possible, set the nameservers to Mozilla so changes don't have to go through somebody else.
I believe there's a 60-day transfer ban. And even if there isn't, or if it's expired, then just before we go live is not the right time to be making this change. Our contact is quite capable of setting up the DNS as we ask him to. Not sure about setting the nameservers; I haven't asked about that. But I'd much rather execute the plan we've prepared for and we know is going to work. Unless you think there's going to be some DNS complexity about this we haven't bargained for? Gerv
(In reply to comment #2) > I believe there's a 60-day transfer ban. Should I even ask why Mozilla wasn't asked to buy this domain in the first place? > Not sure about setting the nameservers; I haven't asked about that. But I'd > much rather execute the plan we've prepared for and we know is going to work. > Unless you think there's going to be some DNS complexity about this we haven't > bargained for? While I can't speak for Mozilla IT, I definitely think you should be using Mozilla's nameservers so IT can easily change things around in DNS at a moment's notice without going through some external person. If something emergency-wise were to happen that required something in DNS to be modified, having to rely on some external individual to make such a change just isn't very wise at all.
(In reply to comment #3) > Should I even ask why Mozilla wasn't asked to buy this domain in the first > place? It's standard practice when attempting to buy a domain name from a speculator that you don't announce who you are. "Ooh! Here come the Mozilla people. They have really deep pockets..." We asked a third party to obtain it for us. > While I can't speak for Mozilla IT, I definitely think you should be using > Mozilla's nameservers so IT can easily change things around in DNS at a > moment's notice without going through some external person. If something > emergency-wise were to happen that required something in DNS to be modified, > having to rely on some external individual to make such a change just isn't > very wise at all. This is certainly not the long-term plan. I completely agree that we should move control over as soon as possible. But not in the middle of site launch. Gerv
Also, when we get to the DB migration step, please save copies of the migrated database(s) so we can give them out as test databases to people who want to hack on the code. Gerv
Another thing: we'll need reverse DNS set up. Otherwise mail might get spam-filtered. Gerv
(In reply to comment #4) > It's standard practice when attempting to buy a domain name from a speculator > that you don't announce who you are. "Ooh! Here come the Mozilla people. They > have really deep pockets..." We asked a third party to obtain it for us. Ah, so it was already owned by somebody, and you just got a 3rd party to purchase it from that person? > This is certainly not the long-term plan. I completely agree that we should > move control over as soon as possible. But not in the middle of site launch. Well, if it was up to me, I wouldn't push this live without Mozilla controlling the nameservers, as there's just too many possible problems with relying on an external party. (In reply to comment #5) > Also, when we get to the DB migration step, please save copies of the migrated > database(s) so we can give them out as test databases to people who want to > hack on the code. Sanitized, I hope? Passwords and e-mail address should be removed... (In reply to comment #6) > Another thing: we'll need reverse DNS set up. Otherwise mail might get > spam-filtered. No, if this site is being hosted on its own VM (instead of the normal cluster), the box just needs to be set up like the normal webheads and use one of the various FQDNs that have been set aside for outgoing mail usage (such as mxout-generic.mozilla.org; exact one will depend on VLAN that the box is in). If this for some reason isn't possible, the app could be set up to smarthost through smtp.mozilla.org, which would also fix this problem.
Yes, my understanding is that it was owned by a speculator. As for sanitized databases: I haven't used an important password on a staging server. I hope no-one else has either... You know more about mail than I do. As long as the mail doesn't get spam-filtered, I don't care how that's done :-) (Note: we need a sensible "From" address which accepts mail and black-holes it, for mail coming from the site. no-reply@drumbeat.org or similar.) Gerv
Hey, it looks like this is not going to happen today. Ran in to a bunch of problems that needed debugging on browserchoice and openchoice.org, which took priority. I plan on picking this back up and making it my #1 priority Sunday night or Monday morning.
Thanks for continuing to drive this Jeremy, and for the update. Looking forward to having it up next week.
I have the stage database copied over and the site is somewhat up at 63.245.209.131 Host: www.drumbeat.org. It looks like it will need some configuring in the admin interface.
There are currently the following differences between the admin status reports https://drumbeat.stage.mozilla.com/admin/reports/status and https://www.drumbeat.org/admin/reports/status (Note: you will be unable to access www.drumbeat.org until either a) DNS is updated, or b) you add the following line to your hosts file and restart your browser: 63.245.209.131 www.drumbeat.org ) 1) The server is unable to contact solr; setting that up requires shell access. 2) The drupal cronjob has been run recently on the staging server, but not on the production server. This is because I added it to crontab this morning, then ran it manually. It needs to be added to crontab on the production server; this also requires shell access. 3) The staging server has a timezone error. Not sure why. I tried setting up the domains stuff correctly, as detailed in https://wiki.mozilla.org/Drumbeat/Website/Install but I can't get www.drumbeat.org to show up as Drumbeat rather than Mozillians. I'll file a bug about that for the Trellon people to look at. I updated some CiviCRM URLs at http://www.drumbeat.org/civicrm/admin/setting/url?reset=1 although I'm not certain if I got the paths right. So I think any further work requires shell access...? Gerv
(Note to us: we should turn off to-user error reporting https://drumbeat.stage.mozilla.com/admin/settings/error-reporting - or equivalent URL - on the production server) Gerv
Will you e-mail me the admin username/password? I don't have access right now.
Done.
Jeremy, The difficulty we have is that the staging server database is a moving target. :-| Therefore, we'd like you to proceed as follows: 1) finish setting up the production server such that we can see the Drumbeat UI when we visit www.drumbeat.org (DNS has now been updated) https://wiki.mozilla.org/Drumbeat/Website/Install 2) ping Mattzilla on IRC, who will disable the staging server so no-one else can add content to it 3) re-migrate the staging server database 4) redo any configuration which is different between the two servers and is stored in the database (e.g. site name) so we are back to a working site again 5) let us know you are done, so we can QA it Ideally stages 2-5 would happen within the space of a few hours, to minimise the "downtime" as we move people over. Let us know if that plan isn't going to work for any reason. Gerv
(In reply to comment #16) > Jeremy, > > The difficulty we have is that the staging server database is a moving target. > :-| > > Therefore, we'd like you to proceed as follows: > > 1) finish setting up the production server such that we can see the Drumbeat > UI when we visit www.drumbeat.org (DNS has now been updated) > https://wiki.mozilla.org/Drumbeat/Website/Install I think I already have all those done.
Not sure why status in prod says it can't connection to the solr server: [root@pm-drumbeat01 ~]# telnet localhost 8983 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'.
Okay, it randomly started working, nm.
* Jeremy has completed initial production server set-up. * Ball is now in Trellon's court to make changes through admin interface to get multi-site working properly. * Matt and Campbell co-ordinated on next steps this aft. Mike Priest or Campbell will make admin changes to get site working properly
* Site is now working in offline mode at drumbeat.org. Must be signed in as admin to view. https://www.drumbeat.org/user * Working to resolve project-specific donation / CiviCRM issue before switching to online mode to begin anonymous user QA * Mike Haggerty will leave status update here before signing off * Gerv will continue with QA
I think this bug can be closed out, since the server is functioning and we are dealing with other issues in separate bugs or IRC.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.