Closed Bug 611573 Opened 15 years ago Closed 15 years ago

[meta] cbo server migration

Categories

(Camino Graveyard :: Product Site, defect)

Product:
Camino Graveyard
Component:
Product Site
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: alqahira, Assigned: ss)

References

Details

(Keywords: meta)

Attachments

(1 file)

Wiki Templates
3.31 KB, text/plain
Details
Stuff we need to be able to do, or need to not regress, with the new server. I feel like something's missing from this initial list, but I can't figure out what :(
So far done: * bug 591659 -- maybe not done; mod_headers is turned on though. * bug 592597 Probably don't need to do bug 526052. Working currently on bug 599968.
* bug 591659 -- maybe not done; mod_headers is turned on though. The htaccess rules are staged in cbo's .htaccess; we just need to uncomment them once we're on the new server.
So far done (mostly): * bug 526052 -- waiting on cert transfer, then verify after switch * bug 591659 -- need to uncomment when we switch * bug 592597 * bug 599968 Todo: * bug 599777 -- planning to rotate logs daily and save them with rotatelogs
(In reply to comment #3) > Todo: > > * bug 599777 -- planning to rotate logs daily and save them with rotatelogs I'd really prefer if we used some more sane period for the SSL log; having to fetch 7 files to do stats each week will be a bit of a pain (plus there's danger of whatever the 'purge old logs' cleanup value is being hit and losing several days' data if whichever of us is currently doing stats is offline for a while). Unless having a several-dozen MB log file is an issue with keeping the server running, I'd really prefer weekly or even fortnightly files.
We can keep them longer, but they're faster to process if they're smaller. I was hoping to eventually automate it which bodes well with daily logs. Also, the purging of logs that's happening automatically now won't be a problem on the new server for one, very good reason: No CPanel. We have complete control over the new server with no hidden random running processes. I can even create a new cron that backs up the directory daily if you want... (And, fwiw, most servers have daily log files so they never have to worry about rotation. Doing rotation manually is very bad, because of instances of some new Brazil Guys visiting and effectively killing SSL.)
(In reply to comment #5) > We can keep them longer, but they're faster to process if they're smaller. Sure, but it's far more complicated to do on a non-daily basis with daily files (and weekly files wouldn't be that slow; I only notice a slowdown when we're above ~300 MB). Currently I can pass in a logfile and a range of days and ignore it until it's done. > was hoping to eventually automate it which bodes well with daily logs. I have no problem switching it back at that point. > the purging of logs that's happening automatically now won't be a problem No, I was referring to automatic log rotation cleanup in comment 4. I.e., Mac OS X rotates logs nightly (and archives them), but it also cleans up after the archived logs; I don't still have archived console.log.10.gz. > create a new cron that backs up the directory daily if you want... I'd be OK with that; we ought see if we can keep the files for a month. > Doing rotation manually is very bad You can't have logrotate do it on a weekly basis; it only does daily?
There will be no automatic log cleanup on the new server, just automatic log rotating. We'll have to manually delete them when we no longer want them. I can rotate on a weekly basis if that makes you feel better. More things to do: * wiki: when migrating and upgrading wiki, I need to re-create all templates and add custom CSS.
Attached file Wiki Templates —
I made this text document of all current wiki templates. Backing up here...
Our cert has been brought over to the new server and is serving properly. Should be good for the switch, but we'll need to verify it. (Right now, it gives an error because the new server isn't hosting "caminobrowser.org" yet, but the cert is definitely there.)
The wiki template issue is actually different than I thought. All of the templates actually did migrate, but now they're in a different form. * Previously: Template:nameOfTemplate * After Migration: Template:NameOfTemplate Because of that, none of the template references are working. I can probably just move them to the proper place, but in case that doesn't work, I'll do a mass change throughout the site for reference to a template. We're still on track to switch to the new server. I'll be blogging the day I need to take the wiki down to back it up and move it over. (And I'll manually update cpo and make sure it hits pmo as well.)
There's some sort of problem with the Rewrite rule for development/roadmap: #RewriteRule ^development/roadmap/?$ http://wiki.caminobrowser.org/Development:Roadmap [R=301,L] Initially, $ and ? were swapped; Apache1 didn't care, but Apache2 was unhappy; however, even after fixing that, it still triggered 500 ISE errors for all rewrites. Once we get the new server up and running, we should look at that and see if we can figure out just what it's unhappy about (I suspect some sort of control character, but I can't tell). For now, however, that redirect is disabled.
I haven't yet heard back from our host, but at this point, we expect to move forward with the migration on Sunday at 3pm PST. This may change, but assuming it doesn't, I'll blog tomorrow about it.
This is happening now.
Status: NEW → ASSIGNED
Current status: * All sites are live * Wiki is working properly, minus some minor issues (Promotion page is broken) * Site is incredibly slow: Host is working on speed * SSL is working, but updates are broken: Host is fixing this
The status hasn't changed since about midnight (EST); so still/now (about 3am EST): * All sites are live on the new server * Wiki is working properly, minus some minor issues (need to adapt to some syntax changes since last version of MW we used) * SSL is working, and updates are working, but slowly (see next item) * All sites are incredibly slow: Host is working on speed
(In reply to comment #15) > * All sites are incredibly slow: Host is working on speed Er, I meant to define slow: it takes me about ~20s to connect, at which point the page loads immediately. However, immediately clicking on another link puts me back in the queue and I have to wait ~20s to connect (as if keep-alive is not working).
Our host wasn't being very responsive, so I had a friend look into the problem. All sites are now running fast and smoothly. There are still minor changes to be made on the wiki, but everything else is live. I'm going to close this bug. If you notice individual problems with any site, please file a bug.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
(In reply to comment #11) > There's some sort of problem with the Rewrite rule for development/roadmap: > > #RewriteRule ^development/roadmap/?$ > http://wiki.caminobrowser.org/Development:Roadmap [R=301,L] > > Initially, $ and ? were swapped; Apache1 didn't care, but Apache2 was unhappy; > however, even after fixing that, it still triggered 500 ISE errors for all > rewrites. Once we get the new server up and running, we should look at that > and see if we can figure out just what it's unhappy about (I suspect some sort > of control character, but I can't tell). For now, however, that redirect is > disabled. This is now bug 619195.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: