|
Grex > Agora > #4: Grex System Problems - Fall 2015/Winter 2016 | |
|
| Author |
Message |
| 25 new of 223 responses total. |
papa
|
|
response 128 of 223:
| 
Jun 13 22:59 UTC 2017 |
bash is my default shell and in my .bashrc I add the directories ~/man and
~/share/man to my MANPATH variable. If I echo $MANPATH, the tilda in the paths
is correctly expanded to /p/a/papa, but if I run man or apropos for an unknown
command, the error message indicates the programs are searching my old home
directory /u/p/a/papa.
|
kentn
|
|
response 129 of 223:
|
Jun 14 01:20 UTC 2017 |
Re: 127, thanks. Yeah it was a bit weird.
|
cross
|
|
response 130 of 223:
|
Jun 14 02:40 UTC 2017 |
resp:128 That's actually correct. /p is a symbolic link to /u/p (don't
ask why...filesystem limitations). So /p/a/papa is /u/p/a/papa; the
error message must expand out the readlink() results into the pathname
(or rather, the commands that generate the error message do that).
|
papa
|
|
response 131 of 223:
|
Jun 14 11:55 UTC 2017 |
OK. No worries then.
|
kentn
|
|
response 132 of 223:
|
Jun 15 00:41 UTC 2017 |
It's almost like having two home directories, but not.
|
telnetuserid
|
|
response 133 of 223:
|
Jun 20 15:48 UTC 2017 |
Regarding local dns resolution for reddit.com, it seems that
grex local dns doesn't cache reddit.com address.
Resolving through google dns works fine.
Does grex local dns server resolve the name through upstream
resolver or recursively querying root servers?
|
telnetuserid
|
|
response 134 of 223:
|
Jun 20 16:03 UTC 2017 |
After viewing /etc/resolv.conf and /var/unbound/etc/unbound.conf
it seems that grex uses both local resolver and google dns servers.
I suggest removing google dns entries in /etc/resolv.conf and enabling
dns forwarding in the unbound.conf
forward-zone:
name: "."
forward-addr: 8.8.8.8
forward-addr: 8.8.4.4
forward-first: yes
Enabling forward-zone should give better dns resolving capability
in the applications and makes better unbound dns caching for
subsequents dns lookup.
|
cross
|
|
response 135 of 223:
|
Jun 20 21:04 UTC 2017 |
That sounds like a reasonable approach; I'll go ahead and implement it.
|
cross
|
|
response 136 of 223:
|
Jun 20 21:07 UTC 2017 |
Setting unbound to forward to the Google DNS servers seems to work.
Given that name servers in /etc/resolv.conf are checked in order, I
don't see a reason to remove 8.8.8.8 or 8.8.4.4; if unbound ever
crashes for whatever peculiar reason, they'll continue to work.
|
jandal
|
|
response 137 of 223:
|
Jun 20 22:09 UTC 2017 |
|
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!
|