Virtual Private Server (VPS) Hosting provided by Central Point Networking cpnllc.com
For some reason, the "Nodelist" and "Recent Callers" features are not working.
| Sysop: | Ray Quinn |
|---|---|
| Location: | Visalia, CA |
| Users: | 50 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 66:36:55 |
| Calls: | 2 |
| Files: | 11,885 |
| Messages: | 148,317 |
Check out the US 99 menu above for links to information about US Highway 99, after which the US 99 BBS is named.
Be sure to click on the Amateur Radio menu item above for packet BBSes, packet software, packet organizations, as well as packet how-to's. Also included is links to local and some not-so-local Amateur Radio Clubs.
I've been seeing an issue with missing file echos files; primarily
with
having multiple TIC files that refer to archives my system does not
appear to have received...
I've been seeing an issue with missing file echos files; primarily with having multiple TIC files that refer to archives my system does not appear t have received...
I've been seeing an issue with missing file echos files; primarily
with having multiple TIC files that refer to archives my system does not
appear t have received...
I have noticed this as well. Also, I've noticed that either you or Gert
is
using "FULLNAME" in the .tic files, which I don't believe is supported.
start htick.log --
Unknown Keyword "FULLNAME" (CRC16=9B31) in TIC File
/sbbs/ftn/fido/insecure/
40d18c4d.tic
-- end htick.log
Which is just one example. Seems every .tic I receive for Linuxnet
reports
this.
Lastly, is Linuxnet going to be fixed any time soon? I, for one,
thought the
importing of newsgroups was a good idea to keep all the echos active,
and
interesting. I enjoyed reading everyday issues, and snippets of code,
etc.
As of right now every echo but this one are completely dead.
I will answer a little on this last one here. :)
IC's News system was got out of work of gating for some month ago, and after this was discovered was the sysop point system and node 1 by mbse setup to f for linux newsgroups, and is still doing it, but maybe mbse not doing it so well at the gating system had done it. But as so far as I know is there stil flowing newsgroups in to linuxnet to ICs system.
Check the linuxnet.traffic echo for mail on to linuxnet.* echos.
I will answer a little on this last one here. :)
IC's News system was got out of work of gating for some month ago, and
after this was discovered was the sysop point system and node 1 by mbse
setup to f for linux newsgroups, and is still doing it, but maybe mbse
not doing it so well at the gating system had done it. But as so far as
I know is there stil flowing newsgroups in to linuxnet to ICs system.
Check the linuxnet.traffic echo for mail on to linuxnet.* echos.
The only echos I'm seeing any traffic in are LINUXNET.ADMIN,
LINUXNET.NEWBIE,
(which is all in a different language anyway, so it doesn't matter much
to me),
LINUXNET.NEWF, and LINUXNET.NEWALLFILE. Every other echo has been dead
for over
a month.
If everything is going good on the ICs end, maybe my uplinks can take a
look into it as well.
I have noticed this as well. Also, I've noticed that either you or
Gert is using "FULLNAME" in the .tic files, which I don't believe is supported.
start htick.log --
Unknown Keyword "FULLNAME" (CRC16=9B31) in TIC File /sbbs/ftn/fido/insecure/ 40d18c4d.tic
-- end htick.log
That could have ben in reason of some ups I can have done and that a
first file sending was bad and then was a new file and tic been send
out. If you still have the tic file then check if what it show for linuxnet file and file echo.
That could have ben in reason of some ups I can have done and that a
first file sending was bad and then was a new file and tic been send
out. If you still have the tic file then check if what it show for
linuxnet file and file echo.
Unlike what I thought, this may be an issue of duplicated TIC files
rather
than that the archive associated with a TIC file not arriving here.
Certainly, that's how the first six tic files are; their associated
archives
are already in my file base, which means that they did arrive here with
a tic file that was processed.
So I'm going to more throughly investigate the rest of them, to see
if it's the same thing with them...
Note also that I do have some archives that showed up in my inbound
without a TIC file, but I haven't decided what I'm going to do with
them...
(Some look to be too old to bother keeping, if they're available
elsewhere...)
That could have ben in reason of some ups I can have done and that a first fil
sending was bad and then was a new file and tic been send out. If you still have the tic file then check if what it show for linuxnet file and file echo.
I thing that the fidogate can be that fidogate is like to do just 32-bit system where my system is a 64-bit system.
all fidogate's main setup and mail news scripts and config files looking for
/usr/lib/ files and the main files for fidogate is directly at /usr/lib64/ and
/news/lib64.
This cna maybe have made that fidogate is gone slow and hangs in
connection to innd's news directories.
The missing flow of linuxnet newsgroup echos is coming from that none of my mbse system have all the news echos in work, and if just fidogate would work without hangs when it runs runtoss commands (options) (4 to 5 options). Commands as runin rungate runnews and send-fidogate is working.
That could have ben in reason of some ups I can have done and that a
first fil sending was bad and then was a new file and tic been send out.
If you still have the tic file then check if what it show for linuxnet
file and file echo.
I'll try freq's for the missing files. If that doesn't work, I'll
send you a list....
I thing that the fidogate can be that fidogate is like to do just 32-bit
system where my system is a 64-bit system.
Well, didn't you rebuild it for the 64 bit system? I did some 64
test
builds of Fidogate, but haven't had a chance yet to actually run it
that way since changing the host lxc system from a 32 to a 64 bit
system.
all fidogate's main setup and mail news scripts and config files looking
for /usr/lib/ files and the main files for fidogate is directly at
/usr/lib64/ and /news/lib64.
Where would something like "/news/lib64" come from?
This can maybe have made that fidogate is gone slow and hangs in
connection to innd's news directories.
Don't forget, there's that setting for where the innd news
directories are
located, depending on which version of inn is being used...
The missing flow of linuxnet newsgroup echos is coming from that none of
my mbse system have all the news echos in work, and if just fidogate
would work without hangs when it runs runtoss commands (options) (4 to 5
options). Commands as runin rungate runnews and send-fidogate is
working.
My system looks to have received a lot of what looks to be catchup
echo
mail in at least some of the gated newsgroups, bringing them up to the
current date...
It could so that either freq to 110:110/2 and 110:300/1 not is working as the sl*.* filebase here not is full why it not liek to take all files in. But freq to 110:300/11 should work why here is it mbsebbs there run and
do it with password work too. Mu system shoudl have nearly the same files as my main system have.
It could so that either freq to 110:110/2 and 110:300/1 not is working
as the sl*.* filebase here not is full why it not liek to take all files
in. But freq to 110:300/11 should work why here is it mbsebbs there run
and do it with password work too. Mu system shoudl have nearly the
same files as my main system have.
I'll keep that in mind, but I may end up not needing to; as you may
have
noticed, I was able to get the issues with quite a few of the TIC files
and their associated archives, and getting them processed. I'll keep
on eye on it, to see if the issues show up again...
RJ Clay wrote to Gert Andersen <=-
Hi Gert!
I've been seeing an issue with missing file echos files; primarily with having multiple TIC files that refer to archives my system does
not appear to have received...
When the first command reported 'couldn't find inndvarshell at /usr/lib/news/lib/
So I search and looked after where it was and it was not in where fidogate looked for it but in the 64-bit libs /lib64/
Then self if my system has both lib32 and lib64 directories and the /usr/lib/* directory is actually the real /lib directory.
Don't forget, there's that setting for where the innd news
directories are located, depending on which version of inn
is being used...
Yes i know that. so Maybe I then should check where the latest newsgroup files and archive is put in /var/ directory for the latest innd version.
When the first command reported 'couldn't find inndvarshell at
/usr/lib/news/lib/
So I search and looked after where it was and it was not in where
fidogate looked for it but in the 64-bit libs /lib64/
Then self if my system has both lib32 and lib64 directories and the
/usr/lib/* directory is actually the real /lib directory.
I don't recall that kind of an issue on my system, but it's been a
while and I'll need to check it anyway...
Don't forget, there's that setting for where the innd news
directories are located, depending on which version of inn
is being used...
Yes i know that. so Maybe I then should check where the latest newsgroup
files and archive is put in /var/ directory for the latest innd version.
That's certainly something to take a look at... When/if I have time
to work
on the packaging for Fidogate again, I'll be taking a look at that
again as well; want to see of there is a way to make that a run time
option rather than a compile time option... (Debian still has both
v1.x & v2.x packages for INN...)