Author Topic: Planned Downtime @ 2018-04-21 00:00:00 GMT. (Read 21281 times)

Monkeh · « **Reply #50 on:** April 23, 2018, 01:52:31 am »

gnif, no DNS records for web1. and web2.eevblog.com - makes my mail server a tad unhappy.

gnif · « **Reply #51 on:** April 23, 2018, 02:11:23 am »

Quote from: Monkeh on April 23, 2018, 01:52:31 am

gnif, no DNS records for web1. and web2.eevblog.com - makes my mail server a tad unhappy.

Your mail server should not be seeing web1.eevblog.com & web2.eevblog.com, they are relaying through cpanel1.eevblog.com which is what you should be seeing. I will double check the logs to confirm however.

gnif · « **Reply #52 on:** April 23, 2018, 02:14:29 am »

Quote from: gnif on April 23, 2018, 02:11:23 am

Quote from: Monkeh on April 23, 2018, 01:52:31 am
gnif, no DNS records for web1. and web2.eevblog.com - makes my mail server a tad unhappy.

Your mail server should not be seeing web1.eevblog.com & web2.eevblog.com, they are relaying through cpanel1.eevblog.com which is what you should be seeing. I will double check the logs to confirm however.

Checked, I see, you are rejecting based on existence of the sending domain. Rather then add records for these hosts (i'd ranter limit their IP exposure) I will adjust the mail server to use plain 'eevblog.com' as the sending domain.

Monkeh · « **Reply #53 on:** April 23, 2018, 02:18:01 am »

Quote from: gnif on April 23, 2018, 02:14:29 am

Quote from: gnif on April 23, 2018, 02:11:23 am
Quote from: Monkeh on April 23, 2018, 01:52:31 am
gnif, no DNS records for web1. and web2.eevblog.com - makes my mail server a tad unhappy.

Your mail server should not be seeing web1.eevblog.com & web2.eevblog.com, they are relaying through cpanel1.eevblog.com which is what you should be seeing. I will double check the logs to confirm however.

Checked, I see, you are rejecting based on existence of the sending domain. Rather then add records for these hosts (i'd ranter limit their IP exposure) I will adjust the mail server to use plain 'eevblog.com' as the sending domain.

Correct. Every little helps. RDNS also appears to need setting up, having looked at full logs.

gnif · « **Reply #54 on:** April 23, 2018, 02:25:55 am »

Quote from: Monkeh on April 23, 2018, 02:18:01 am

Quote from: gnif on April 23, 2018, 02:14:29 am
Quote from: gnif on April 23, 2018, 02:11:23 am
Quote from: Monkeh on April 23, 2018, 01:52:31 am
gnif, no DNS records for web1. and web2.eevblog.com - makes my mail server a tad unhappy.

Your mail server should not be seeing web1.eevblog.com & web2.eevblog.com, they are relaying through cpanel1.eevblog.com which is what you should be seeing. I will double check the logs to confirm however.

Checked, I see, you are rejecting based on existence of the sending domain. Rather then add records for these hosts (i'd ranter limit their IP exposure) I will adjust the mail server to use plain 'eevblog.com' as the sending domain.

Correct. Every little helps. RDNS also appears to need setting up, having looked at full logs.

This has been requested already, I need to chase the DC to find out why this has not happened yet.

gnif · « **Reply #55 on:** April 23, 2018, 07:08:53 am »

rDNS records are now in place, please allow up to 24 hours for caches to clear

Cerebus · « **Reply #56 on:** April 23, 2018, 01:10:38 pm »

You might get problems as the forward and reverse DNS don't agree for your named MX host:

nuit$ dig +short eevblog.com mx 0 mail.eevblog.com. nuit$ dig +short mail.eevblog.com 192.200.109.226 nuit$ dig +short -x 192.200.109.226 cpanel1.eevblog.com. nuit$

Some people will reject mail on that basis, some won't.

gnif · « **Reply #57 on:** April 23, 2018, 01:23:43 pm »

Quote from: Cerebus on April 23, 2018, 01:10:38 pm

You might get problems as the forward and reverse DNS don't agree for your named MX host:

nuit$ dig +short eevblog.com mx 0 mail.eevblog.com. nuit$ dig +short mail.eevblog.com 192.200.109.226 nuit$ dig +short -x 192.200.109.226 cpanel1.eevblog.com. nuit$

Some people will reject mail on that basis, some won't.

That's not how rDNS filtering works, it looks for the forward and reverse DNS to match, it doesn't care about MX records, otherwise services like gmail and office365 would be plagued with the same problem.

Code: [Select]

# host 192.200.109.226
226.109.200.192.in-addr.arpa domain name pointer cpanel1.eevblog.com.
# host cpanel1.eevblog.com.
cpanel1.eevblog.com has address 192.200.109.226

Here is gmail.

Code: [Select]

# nslookup
> set type=mx
> gmail.com
Server:		redacted
Address:	redacted#53

Non-authoritative answer:
gmail.com	mail exchanger = 10 alt1.gmail-smtp-in.l.google.com.
gmail.com	mail exchanger = 30 alt3.gmail-smtp-in.l.google.com.
gmail.com	mail exchanger = 40 alt4.gmail-smtp-in.l.google.com.
gmail.com	mail exchanger = 5 gmail-smtp-in.l.google.com.
gmail.com	mail exchanger = 20 alt2.gmail-smtp-in.l.google.com.

Code: [Select]

> set type=a
> alt1.gmail-smtp-in.l.google.com
Server:		redacted
Address:	redacted#53

Non-authoritative answer:
Name:	alt1.gmail-smtp-in.l.google.com
Address: 64.233.179.27

Code: [Select]

# host 64.233.179.27
27.179.233.64.in-addr.arpa domain name pointer om-in-f27.1e100.net.
# host om-in-f27.1e100.net.
om-in-f27.1e100.net has address 64.233.179.27
om-in-f27.1e100.net has address 66.102.12.27
om-in-f27.1e100.net has address 216.239.32.27

All that matters is the SMTP server has the rDNS resolve to the forward DNS.

geekGee · « **Reply #58 on:** April 23, 2018, 01:34:11 pm »

It could impact an SPF record check but you've already mitigated that.

eevblog.com. 299 IN TXT "v=spf1 +a +mx ~all"

gnif · « **Reply #59 on:** April 23, 2018, 02:34:49 pm »

Quote from: geekGee on April 23, 2018, 01:34:11 pm

It could impact an SPF record check but you've already mitigated that.

eevblog.com. 299 IN TXT "v=spf1 +a +mx ~all"

That doesn't apply here either, the web servers relay via the mx server. Technically "a" should not be in the SPF record since the website is proxied via CloudFlare, and the "a" is giving CloudFlare permission to send email from the domain.

geekGee · « **Reply #60 on:** April 23, 2018, 03:05:11 pm »

Quote from: gnif on April 23, 2018, 02:34:49 pm

Quote from: geekGee on April 23, 2018, 01:34:11 pm
It could impact an SPF record check but you've already mitigated that.

eevblog.com. 299 IN TXT "v=spf1 +a +mx ~all"

That doesn't apply here either, the web servers relay via the mx server. Technically "a" should not be in the SPF record since the website is proxied via CloudFlare, and the "a" is giving CloudFlare permission to send email from the domain.

Ah... now I see. Entries cpanel1 and mail resolve to the same IP address.

gnif · « **Reply #61 on:** April 24, 2018, 12:40:10 am »

Outage just now was caused by SMF attempting to "Optimize" the tables, I will need to adjust SMF to prevent this behavior.

Edit: SMF patched, this should not reoccur.

EEVblog · « **Reply #62 on:** April 24, 2018, 01:29:37 am »

Quote from: gnif on April 24, 2018, 12:40:10 am

Outage just now was caused by SMF attempting to "Optimize" the tables, I will need to adjust SMF to prevent this behavior.
Edit: SMF patched, this should not reoccur.

Thanks.
I occasionally "optimise" the tables manually in the admin section option just to keep things tidy.
Can/should I still do this?

gnif · « **Reply #63 on:** April 24, 2018, 04:42:22 am »

Quote from: EEVblog on April 24, 2018, 01:29:37 am

Quote from: gnif on April 24, 2018, 12:40:10 am
Outage just now was caused by SMF attempting to "Optimize" the tables, I will need to adjust SMF to prevent this behavior.
Edit: SMF patched, this should not reoccur.

Thanks.
I occasionally "optimise" the tables manually in the admin section option just to keep things tidy.
Can/should I still do this?

Previously this was fine but part of the move meant changing to a different storage engine and data format type, the optimize query literally rewrites each table in the entire database. The new format and highly optimized cluster configuration, as well as having enough ram to keep the entire data set in ram makes this an unnecessary step.

Rerouter · « **Reply #64 on:** April 24, 2018, 10:15:32 am »

As server juggling is going on, felt I should point out there have been a few times tonight where i have had the eevblog server fail to return a page after posting a reply, Refreshing fixes it,

Edit: Exact response is "Server gave an empty response" and happened twice while i was trying to post this message,

gnif · « **Reply #65 on:** April 25, 2018, 12:56:11 am »

Update: The Wiki is back

BU508A · « **Reply #66 on:** April 27, 2018, 08:55:58 am »

Quote from: gnif on April 23, 2018, 01:35:39 am

Ok, I will have another dig though, it does seem very odd that it intermittent as everything is in sync.

Certainly not overloaded, perhaps there is a plugin still trying to use the old database configuration.

gnif, whatever you did, it seems that since yesterday the database error did not show up again on my iPad.
Thank you very much for resolving this.

Andreas

hwj-d · « **Reply #67 on:** April 27, 2018, 11:41:36 pm »

Even with me this annoying database error is gone now.
Thanks too.

But, what was it? I would be interested...

gnif · « **Reply #68 on:** April 28, 2018, 05:23:32 am »

Quote from: hwj-d on April 27, 2018, 11:41:36 pm

But, what was it? I would be interested...

It was extremely simple, CloudFlare were caching the error pages from during the server migration and would not flush them. After discussion with Dave CF has been disabled and will only be re-enabled if we need to use it to help mitigate against an attack.

gnif · « **Reply #69 on:** April 28, 2018, 06:38:17 am »

Quote from: wilfred on April 28, 2018, 06:18:46 am

Quote from: gnif on April 28, 2018, 05:23:32 am
Quote from: hwj-d on April 27, 2018, 11:41:36 pm
But, what was it? I would be interested...

It was extremely simple, CloudFlare were caching the error pages from during the server migration and would not flush them. After discussion with Dave CF has been disabled and will only be re-enabled if we need to use it to help mitigate against an attack.

When you say would not flush them do you mean they refused a request or the command you can issue for your site didn't work? What was the reason CF was enabled in the first place? Does the reason still exist with the new server setup?

CloudFlare would flush their cache (via the portal) but not globally, some of their nodes still (even today) cached the database error pages that occurred during the upgrade. CF was enabled to try to reduce load on the single server that Dave had early on.

I just posted on Patreon (no need to be a patron to read my posts) a write up on this entire move, the server configuration basics, etc. if anyone is interested.
https://www.patreon.com/posts/18456501

frozenfrogz · « **Reply #70 on:** April 28, 2018, 10:52:41 am »

Thanks for the write up!
I do not understand half of the technical intricacies regarding web servers and network management, but it was a nice read none the less.

hwj-d · « **Reply #71 on:** April 29, 2018, 12:15:45 am »

Quote

I just posted on Patreon (no need to be a patron to read my posts) a write up on this entire move, the server configuration basics, etc. if anyone is interested.
https://www.patreon.com/posts/18456501

Wow, what a story. Thanks for writing and sharing it all.

And now, i think, i want to learn what puppet is and makes ...

Thanks again.

jc101 · « **Reply #72 on:** April 30, 2018, 05:37:56 pm »

Since the update when I go to look in...

https://www.eevblog.com/forum/dodgy-technology/

I just get a blank page. However if from the forum I click the icon next to the forum, ( https://www.eevblog.com/forum/dodgy-technology/?action=unread;children ) to get just the new posts, I do get to see the list.

I get the same behaviour on Safari, Chrome, and Firefox. Using http or https.

Is this a hangover from the server change?


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: Planned Downtime @ 2018-04-21 00:00:00 GMT. (Read 21281 times)

Share me