rpt_extnodes-temp should never show up. And the fact that it is 0 length
indicates that it is likely that the resolver on your node may be
inoperative. Check to make sure FQDN's resolve on these systems.
Hi guys, Ok I checked a couple of the other nodes here like 2379, 2357. All on different public Ips and I'm seeing the same thing.
The rpt_extnodes is showing Aug 18 and I also have the rpt_extnodes-temp files too.
I'm not using FQDNs or Dynamic Dns for the IPs on these nodes.
yes I had 2 nodes on the same router as I mentioned earlier so I took 2377 off line but the rest of the nodes are not getting updated.
Looks like Aug 18 was the last time the nodes I look after were updated.
It just seems strange that a bunch of nodes up here are not getting updated.
Jon RQ
Stephen Rodgers wrote:
···
Ramesh Dhami (VA3UV) wrote:
Hi Steve / Jim;
I've noticed that the rpt_extnodes file has not been updating recently...
Here's the file info from #2200:
-rwx------ 1 root root 14713 Aug 20 21:41 rpt_extnodes
-rw-r--r-- 1 root root 0 Aug 22 08:41 rpt_extnodes-temp
Here's the file info from #2461, which I have been soak testing here for the past week, and intend to send it back to its owner today:
-rwx------ 1 root root 14717 Aug 18 00:15 rpt_extnodes
-rw-r--r-- 1 root root 0 Aug 22 08:44 rpt_extnodes-temp
Notice that the temp file is being created, so the script is running, but obviously failing (to connect to the server perhaps?)
rpt_extnodes-temp should never show up. And the fact that it is 0 length
indicates that it is likely that the resolver on your node may be
inoperative. Check to make sure FQDN's resolve on these systems.
rpt_extnodes-temp should never show up. And the fact that it is 0 length
indicates that it is likely that the resolver on your node may be
inoperative. Check to make sure FQDN's resolve on these systems.
<-- Hi Steve; Node 2200 is in a hospital DC, using their DNS; I just logged in and ping'd a few FQDN's and they all resolved perfectly.
Further, after posting my note this morning, I went into the rpt.conf file on 2200 and added 2461 to the list of nodes that are allowed to connect - i.e., a manual entry at the bottom of the file, and used the FQDN for 2461 (not the IP addr), and after that I was able to successfully connect 2461 to 2200.
So I don't think it is a DNS issue... esp., since Jon (RQ) is seeing this issue independently on a couple of his nodes.
rpt_extnodes-temp should never show up. And the fact that it is 0 length
indicates that it is likely that the resolver on your node may be
inoperative. Check to make sure FQDN's resolve on these systems.
rpt_extnodes-temp should never show up. And the fact that it is 0 length
indicates that it is likely that the resolver on your node may be
inoperative. Check to make sure FQDN's resolve on these systems.
I updated rc.updatenodelist on my ACID based install to use nodes1-4 and my -temp file went away, and was replaced with a freshly dated rpt_extnodes file.
Jim
···
On Aug 22, 2009, at 10:48 AM, James Nessen wrote:
I think I found the issue..
rc.updatenodelist on my limey linux machine looks at:
SUBDOMAINS="nodes1 nodes2 nodes3 nodes4"
whereas on an acid install it looks at:
SUBDOMAINS="nodes1"
running the command manually on my ACID based install gives me:
[root@asterisk-2144 asterisk]# wget http://nodes1.allstarlink.org/cgi-bin/nodes.pl
--10:50:14-- http://nodes1.allstarlink.org/cgi-bin/nodes.pl
Resolving nodes1.allstarlink.org... 209.134.25.160
Connecting to nodes1.allstarlink.org|209.134.25.160|:80... connected.
HTTP request sent, awaiting response... 500 Internal Server Error
10:50:14 ERROR 500: Internal Server Error.
So, maybe an issue with this nodes1 server?
Jim, K6JWN
On Aug 22, 2009, at 8:00 AM, Stephen Rodgers wrote:
Ramesh Dhami (VA3UV) wrote:
Hi Steve / Jim;
I've noticed that the rpt_extnodes file has not been updating recently...
Here's the file info from #2200:
-rwx------ 1 root root 14713 Aug 20 21:41 rpt_extnodes
-rw-r--r-- 1 root root 0 Aug 22 08:41 rpt_extnodes-temp
Here's the file info from #2461, which I have been soak testing here for
the past week, and intend to send it back to its owner today:
-rwx------ 1 root root 14717 Aug 18 00:15 rpt_extnodes
-rw-r--r-- 1 root root 0 Aug 22 08:44 rpt_extnodes-temp
Notice that the temp file is being created, so the script is running,
but obviously failing (to connect to the server perhaps?)
rpt_extnodes-temp should never show up. And the fact that it is 0 length
indicates that it is likely that the resolver on your node may be
inoperative. Check to make sure FQDN's resolve on these systems.
I updated rc.updatenodelist on my ACID based install to use nodes1-4
and my -temp file went away, and was replaced with a freshly dated
rpt_extnodes file.
Jim
I think I found the issue..
rc.updatenodelist on my limey linux machine looks at:
SUBDOMAINS="nodes1 nodes2 nodes3 nodes4"
whereas on an acid install it looks at:
SUBDOMAINS="nodes1"
running the command manually on my ACID based install gives me:
[root@asterisk-2144 asterisk]# wget http://nodes1.allstarlink.org/cgi-bin/nodes.pl
--10:50:14-- http://nodes1.allstarlink.org/cgi-bin/nodes.pl
Resolving nodes1.allstarlink.org... 209.134.25.160
Connecting to nodes1.allstarlink.org|209.134.25.160|:80... connected.
HTTP request sent, awaiting response... 500 Internal Server Error
10:50:14 ERROR 500: Internal Server Error.
So, maybe an issue with this nodes1 server?
Jim, K6JWN
Ramesh Dhami (VA3UV) wrote:
Hi Steve / Jim;
I've noticed that the rpt_extnodes file has not been updating
recently...
Here's the file info from #2200:
-rwx------ 1 root root 14713 Aug 20 21:41 rpt_extnodes
-rw-r--r-- 1 root root 0 Aug 22 08:41 rpt_extnodes-temp
Here's the file info from #2461, which I have been soak testing
here for
the past week, and intend to send it back to its owner today:
-rwx------ 1 root root 14717 Aug 18 00:15 rpt_extnodes
-rw-r--r-- 1 root root 0 Aug 22 08:44 rpt_extnodes-temp
Notice that the temp file is being created, so the script is
running,
but obviously failing (to connect to the server perhaps?)
rpt_extnodes-temp should never show up. And the fact that it is 0
length
indicates that it is likely that the resolver on your node may be
inoperative. Check to make sure FQDN's resolve on these systems.
Pass to it an argument for the specific nodes server you wish to test
(i.e. nodes1, nodes2).
For all acid users, I recommend they edit the rc.updatenodeslist and
make sure nodes2.allstarlink.org is specified in addition to
nodes1.allstarlink.org like this:
SUBDOMAINS="nodes1 nodes2"
ACID gets rc.updatenodelist from files.tar.gz in the allstar directory,
and copies it to /etc/rc.d/rc.updatenodelist during installation. This
is a different file than what limey linux uses. I since updated the file
in SVN to include nodes2, but all the existing systems will
not see this update as the script is already installed.
Steve
WA6ZFT
···
On Aug 22, 2009, at 10:48 AM, James Nessen wrote:
On Aug 22, 2009, at 8:00 AM, Stephen Rodgers wrote:
Once again, someone had a “better idea” and made a “security” change in Cpanel
and BROKE the distribution code running on nodes1.allstarlink.org.
I was able to make a horrible kludge to get it up temporarily while I find new
hoster for it that DOES NOT USE CPANEL or anything like it!!! This makes about
the 4th time Ive had to spend hours coding around one of their “security patches”.
So, for the time being, the rpt_extnodes file should be okay, but watch out, with the
way its working now, there is a tiny, i mean really tiny chance that the file that it
downloads to you may be truncated (not completely internally populated yet). I
have no control over this as it stands.
Thank you Cpanel, for ruining another day of my life!!!
P.S. for those of you who have never had the “honor” of using Cpanel, or
even knowing what it is, its a front-end that hosting services generally use
for “hand-holding” their hosting users. Its a graphical do-it-yourself admin
interface.
Well... I don't get anything for referring people, but I'm a teir-3 admin
here at Go Daddy, and they offer dedicated hosting with or without that
cpanel crap.
Have to agree though...the panel software really screws things up so that
you can't do anything safely outside their interface. Don't think any of
the guys here like it.
-Dan N7NMD
···
___
...... Original Message .......
On Sat, 22 Aug 2009 15:35:15 -0700 "Jim Duuuude" <telesistant@hotmail.com> wrote: