|
Grex > Agora > #4: Grex System Problems - Fall 2015/Winter 2016 | |
|
| Author |
Message |
| 25 new of 223 responses total. |
jandal
|
|
response 138 of 223:
| 
Jun 20 22:15 UTC 2017 |
I am unable to send mail to grex.
----- Transcript of session follows -----
... while talking to grex.org.:
>>> DATA
<<< 554 5.7.1 Service unavailable; Client host [205.166.94.20] blocked
using multi.uribl.com; 127.0.0.1 -> Query Refused.
See http://uribl.com/refused.shtml for more information
[Your DNS IP: 173.194.94.133]
554 5.0.0 Service unavailable
<<< 554 5.5.1 Error: no valid recipients
Reading the referred page, I see:
> If an email you sent bounced, and included a link to this page, then
> it was rejected because the receiver has not implemented URIBL lookups
> correctly.
Please note that I don't use grex as my mail mailserver; however this
still seems like a system problem that should be reported.
|
jandal
|
|
response 139 of 223:
|
Jun 20 22:18 UTC 2017 |
PS. Further, I read on the above-mentioned page:
> Possibly changing your nameservers from a public dns provider (ie
> opendns/google) to your local ISP may solve it.
Is this issue a result of the recent DNS changes discussed above?
|
telnetuserid
|
|
response 140 of 223:
|
Jun 21 01:40 UTC 2017 |
The downside of using dns forwarding to public dns server
is uribl will prevent sending mails to grex.
There is an alternative to solve the issue. Instead of
using dns forwarding, add an updated root-hint file so
that the dns resolver will query root-servers and prevent
dns blacklisting on grex.
Unbound has built-in root-hint, but it's often outdated.
The updated root-hint file can be obtained from
https://www.iana.org/domains/root/files
The unbound.conf needs to be updated to include
root-hints: /path/to/updated/root-hint
|
cross
|
|
response 141 of 223:
|
Jun 21 14:02 UTC 2017 |
Perhaps I'm missing something, but it seems like not forwarding to the public
servers puts us back into the same boat with e.g. reddit that we made this
change to get out of in the first place. Am I missing something here?
|
jhesse
|
|
response 142 of 223:
|
Jun 21 16:05 UTC 2017 |
Re: #138: Got the same bounce on a test message. No new emails since Monday.
|
cross
|
|
response 143 of 223:
|
Jun 21 17:47 UTC 2017 |
Try again: I've reset Grex's DNS configuration to be substantially similar
to what it was before.
|
cross
|
|
response 144 of 223:
|
Jun 21 18:54 UTC 2017 |
Actually, uribl.com wasn't happy at the rate of queries directly from Grex,
either, so I've disabled it. Sadly, this will allow more spam through; but
it will also allow real mail in, too.
unbound is now forwarding to 8.8.8.8 and 8.8.4.4 again, so resolving
'reddit.com' works again.
|
kentn
|
|
response 145 of 223:
|
Jun 22 01:27 UTC 2017 |
Here's what I'm getting with RT now:
"RT has detected a possible cross-site request forgery for this request,
because the Referrer header supplied by your browser (www.grex.org:443)
is not allowed by RT's configured hostname (grex.org:443). A malicious
attacker may be trying to update a ticket on your behalf. If you did not
initiate this request, then you should alert your security team."
Then you have to click a link to continue. I have to do this a couple
times to respond to a ticket. This started after the most recent
changes to the dns, etc. Is there some way to fix RT so it doesn't do
this and lets me respond to tickets easily like it used to? Looks like
it might be the difference between www.grex.org and just grex.org.
|
cross
|
|
response 146 of 223:
|
Jun 22 02:54 UTC 2017 |
Hmm. Are you connecting to https://www.grex.org/ or https://grex.org?
You should always use the latter.
|
kentn
|
|
response 147 of 223:
|
Jun 22 11:32 UTC 2017 |
I'm connecting to https://grex.org/. If the browser adds "www." I don't
see it.
|
cross
|
|
response 148 of 223:
|
Jun 22 14:38 UTC 2017 |
Hmm. That's weird; I can't seem to reproduce it....
|
telnetuserid
|
|
response 149 of 223:
|
Jun 23 09:30 UTC 2017 |
For redirecting www.grex.org to grex.org, I think a http
server rewrite rule is sufficient.
|
telnetuserid
|
|
response 150 of 223:
|
Jun 24 15:45 UTC 2017 |
I mean, the http server need to give 301 response when
a GET request to www.grex.org performed, redirecting
the request to correct domain.
Here is nginx configuration snippet to do that.
server {
server_name www.grex.org;
return 301 $scheme://example.org$request_uri;
}
|
tonster
|
|
response 151 of 223:
|
Jun 25 23:21 UTC 2017 |
resp:144: feel free to use 99.95.107.130, 45.33.105.232, and
45.79.186.112 for DNS forwards. They're my caching nameservers and are
already configured to allow queries from my block.
|
kentn
|
|
response 152 of 223:
|
Oct 29 17:54 UTC 2017 |
Obviously, grex was unavailable for several days this past week. There
was a network hardware issue and it took a while to get hardware
replaced and hooked back up. I just got to grex via grex.org, so
that is working again. cyberspace.org works okay, too. New IP is
75.61.90.157. DNS is catching up with this change and most everything
should be working now, or will be soon.
Thanks to Tony for getting us going again!
|
tod
|
|
response 153 of 223:
|
Oct 31 16:30 UTC 2017 |
Thanks
|
kentn
|
|
response 154 of 223:
|
Apr 18 12:09 UTC 2018 |
Grex was offline for a while in the last couple days. This was due to
the huge ice storm that came through and knocked out the electricity in
a lot of areas around here.
Where I'm at the electricity was off for 4 hours, which is more than
enough for most UPSes to run out of energy to keep things going.
Tony was able to successfully booted again. Thank you, Tony!
|
papa
|
|
response 155 of 223:
|
Apr 18 12:46 UTC 2018 |
resp:154
Glad Grex is back up. Thank you Tony and Kent.
|
kentn
|
|
response 156 of 223:
|
Apr 20 21:17 UTC 2018 |
There have been some reports of connection and application issues since
we brought Grex back up. The web site and ssh should be working again
and so should mutt and mc. The RT help desk app doesn't seem to be
working right now so I'm unable to reply to validation and help requests
even though I can, when I find the time, work on them.
|
cross
|
|
response 157 of 223:
|
Apr 20 23:13 UTC 2018 |
resp:156 What exactly is not working? Any error messages?
|
kentn
|
|
response 158 of 223:
|
Apr 20 23:43 UTC 2018 |
Right now, it is a case of Firefox can't connect, but earlier it said
to contact the administrator (and that was all).
|
cross
|
|
response 159 of 223:
|
Apr 21 01:54 UTC 2018 |
Hmm. It seems some file permissions were wrong; probably due to
me upgrading the web server. Are you still having problems? I'm
able to get into RT, but didn't try to do anything....
|
kentn
|
|
response 160 of 223:
|
Apr 21 14:39 UTC 2018 |
It's working for me now. Thanks!
|
kentn
|
|
response 161 of 223:
|
May 29 19:51 UTC 2018 |
E-mail may not be working for you if it requires a SSL certificate to
be up to date. Grex's SSL certs expired today and that seems to be one
reason. Another reason is that grex tends to be blacklisted on some
popular sites including gmail. My iphone was complaining about every
15 seconds that grex.org was not verified and it said the SSL cert had
expired.
|
glitch
|
|
response 162 of 223:
|
Jun 5 20:58 UTC 2018 |
SSH is quite laggy, I'm logged in to a handful of other systems for work and
have no issues there, so I'm pretty sure it's not me.
Seems that the SSL cert has expired for Backtalk. Since we're on OpenBSD 6.3
here, we've got acmetool (a client for LetsEncrypt) right in the base OS --
not only are the certs free, but the update process can (and should!) be
automated with a cron job or /etc/daily.local entry. Ping me for help, I run
OpenBSD servers for $day_job :)
Finally, it seems /var/mail/glitch is gone and I can't get email here at the
moment.
|