All,

What is the prupose of the var/ticqueue directory and does it ever get cleaned up? When I orignally went to bring up a backup of my MbseBBS system on a new system, I found files there going back some 10 years. 'Course, most of those older ones would have been under v0.97, IIRC, as I didn't upgrade the install to a newer version until I had it running again...


Jame


Greetings, Rj Clay
email: admftn@ftn.rocasa.net

--- MBSE BBS v1.0.6.8 (GNU/Linux-i386)
* Origin: ftn.rocasa.net (1:120/544)

Hello Rj!

Friday December 01 2017 08:44, you wrote to All:

All,

What is the prupose of the var/ticqueue directory and does it ever
get cleaned up? When I orignally went to bring up a backup of my
MbseBBS system on a new system, I found files there going back some 10 years. 'Course, most of those older ones would have been under v0.97,
IIRC, as I didn't upgrade the install to a newer version until I had
it running again...

Hold all of the active .tic files so if empty you should have no o/p when running mbout sta (apart from the headings and version info.

So if restoring from an old back up suggest you delete them and likewise the contents of var/bso/outbound* but keep the directories.

outbound* = outbound.001 , .002, .003 and .004 your own zone will be just outbound without any number after.

Oh, you could also have other nets here as well so delete the contents.


Vince

--- Mageia Linux v5.1/Mbse v1.0.7.4/GoldED+/LNX 1.1.501-b20150715
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

Hello Rj!

01 Dec 17 08:44, you wrote to all:

What is the prupose of the var/ticqueue directory and does it ever
get cleaned up? When I orignally went to bring up a backup of my
MbseBBS system on a new system, I found files there going back some 10 years. 'Course, most of those older ones would have been under v0.97, IIRC, as I didn't upgrade the install to a newer version until I had
it running again...

The var/ticqueue directory holds .tic files until they are sent to the receiving system. They should be deleted automatically after they are sent. Checking mine, I have a few going back as far as March; I'll have to check on why they are still hanging out.

After a quick check, those were leftovers from a system that went down and never picked them up.

Any .tic files in there that are not for active downlinks can (and should be) deleted.

Andrew

--- GoldED+/LNX 1.1.5-b20170303
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

Hi Vince!

Vince Coen wrote to Rj Clay:

Hello Rj!

Friday December 01 2017 08:44, you wrote to All:

All,

What is the prupose of the var/ticqueue directory and does it ever get cleaned up? When I orignally went to bring up a backup of my
MbseBBS system on a new system, I found files there going back some 10 years. 'Course, most of those older ones would have been under v0.97, IIRC, as I didn't upgrade the install to a newer version until I had
it running again...

Hold all of the active .tic files so if empty you should have no o/p when running mbout sta (apart from the headings and version info.

So inactive .tic files would be ones that have already been sent, and at least in more recent versions get automatically cleaed up? (That was one of concerns as lots of tiny files can really jump up inode usage...)

So if restoring from an old back up suggest you delete them

That, I've done.

and likewise
the contents of var/bso/outbound* but keep the directories.

outbound* = outbound.001 , .002, .003 and .004 your own zone will be just outbound without any number after.

Oh, you could also have other nets here as well so delete the contents.

Hmmm... I don't think I've really checked all of those, so I'll be reviewing their contents.




Jame


Greetings, Rj Clay
email: admftn@ftn.rocasa.net

--- MBSE BBS v1.0.6.8 (GNU/Linux-i386)
* Origin: ftn.rocasa.net (1:120/544)

Hi Vince!

Vince Coen wrote to Rj Clay:

Hello Rj!

Friday December 01 2017 08:44, you wrote to All:

What is the prupose of the var/ticqueue directory and does it ever get cleaned up? ....

Hold all of the active .tic files so if empty you should have no o/p when running mbout sta (apart from the headings and version info.

So if restoring from an old back up suggest you delete them and likewise the contents of var/bso/outbound* but keep the directories.

Those all I still need to finish reviewing, as not only are there still .sts
(status files, IIRC?) going back as far as 2004 but there are also things like .flo files timestamped from 2010. The old *.sts files can likely be removed but things like those old .flo files I'll need to check more closely.

On a separate issue; I've also found a number of *.sa# (where "#" is a single
digit) files that have zero size, all from earier this morning at different times. I'll have to check the logs to see if there's anything about what might
have happened.

outbound* = outbound.001 , .002, .003 and .004 your own zone will be just outbound without any number after.

Oh, you could also have other nets here as well so delete the contents.

Yes, I do indeed; a number of which haven't been touched for over a decade. Preumably, if they also have only old *.sts file or are empty then they can just
be deleted. (And would be recreated again if needed...)



Jame


Greetings, Rj Clay
email: admftn@ftn.rocasa.net

--- MBSE BBS v1.0.6.8 (GNU/Linux-i386)
* Origin: ftn.rocasa.net (1:120/544)

Hello Rj!

Saturday December 02 2017 04:58, you wrote to me:

Hi Vince!

Vince Coen wrote to Rj Clay:

Hello Rj!

Friday December 01 2017 08:44, you wrote to All:

All,

What is the prupose of the var/ticqueue directory and does

it ever

get cleaned up? When I orignally went to bring up a backup of

my

MbseBBS system on a new system, I found files there going back

some 10

years. 'Course, most of those older ones would have been under

v0.97,

IIRC, as I didn't upgrade the install to a newer version until

I had

it running again...

Hold all of the active .tic files so if empty you should have no
o/p when running mbout sta (apart from the headings and version
info.

So inactive .tic files would be ones that have already been sent,
and at least in more recent versions get automatically cleaed up?
(That was one of concerns as lots of tiny files can really jump up
inode usage...)

The nightly script clears these and files/mail that has been sent out from the outbound directories etc but after the files / mail have been sent there is a clean up hence when running mbout sta after a poll anything that was on hold is
no longer shown.

As you are restoring an OLD back up the various directories that I discused in a previous email should be cleared if not only for the fact that any nodes set up in the system will need to be verified if you still need them (assuming they
are still around and you are acting as a down/up link for them.

So if restoring from an old back up suggest you delete them

That, I've done.

and likewise
the contents of var/bso/outbound* but keep the directories.

outbound* = outbound.001 , .002, .003 and .004 your own zone will
be just outbound without any number after.

Oh, you could also have other nets here as well so delete the
contents.

Hmmm... I don't think I've really checked all of those, so I'll be reviewing their contents.

As said above you will need to check your settings for up/down links and reset/delete/update them, file and mail areas you are connected to may also need changing, your aka's may also need to be changed.

If you are going to use mbse over a previous BBS then you may well also want to
adopt all of the various bbs file areas into mbse using mbfile.

Jame

Greetings, Rj Clay
email: admftn@ftn.rocasa.net

That should keep you occupied for an hour or so.

Vince

--- Mageia Linux v5.1/Mbse v1.0.7.4/GoldED+/LNX 1.1.501-b20150715
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

Hello Rj!

Saturday December 02 2017 07:30, you wrote to me:

Hi Vince!

Vince Coen wrote to Rj Clay:

Hello Rj!

Friday December 01 2017 08:44, you wrote to All:

What is the prupose of the var/ticqueue directory and does

it ever

get cleaned up? ....

Hold all of the active .tic files so if empty you should have no
o/p when running mbout sta (apart from the headings and version
info.

So if restoring from an old back up suggest you delete them and
likewise the contents of var/bso/outbound* but keep the
directories.

Those all I still need to finish reviewing, as not only are there
still .sts (status files, IIRC?) going back as far as 2004 but there
are also things like .flo files timestamped from 2010. The old *.sts
files can likely be removed but things like those old .flo files I'll
need to check more closely.

On a separate issue; I've also found a number of *.sa# (where "#"
is a single digit) files that have zero size, all from earier this
morning at different times. I'll have to check the logs to see if
there's anything about what might have happened.

The zero file sizes are as a result of mbse doing a clean up and if mbse is not
yet connecting to other sites up or down you can delete the lot.
They will be recreated when needed once your system is operational.

outbound* = outbound.001 , .002, .003 and .004 your own zone will
be just outbound without any number after.

Oh, you could also have other nets here as well so delete the
contents.

Yes, I do indeed; a number of which haven't been touched for over a decade. Preumably, if they also have only old *.sts file or are empty
then they can just be deleted. (And would be recreated again if
needed...)

Yes.

Before I forget the current version that sits in the source repo is 1.0.7.4. While the files area it is 1.0.7.2 the difference being one file see the Changelog.

My system has a few changes that is for me but mostly related to the sizing of filefind output as I increased all values.

Vince

--- Mageia Linux v5.1/Mbse v1.0.7.4/GoldED+/LNX 1.1.501-b20150715
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

On 2017 Dec 02 07:30:58, you wrote to Vince Coen:

On a separate issue; I've also found a number of *.sa# (where "#" is a single digit) files that have zero size, all from earier this morning
at different times. I'll have to check the logs to see if there's anything about what might have happened.

these are likely mail bundles (mo1, tu3, sa4) that have been sent and truncated
after sending so the tosser knows to increment the bundle number the next time it creates a bundle for that destination node... if you stop bundling and just send raw PKTs, the PKTs should be deleted after sending and you won't have zero
byte files laying around... we don't really need bundling these days, anyway...
some mailers can compress on the fly and compress better than zip or arj or whatever...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Don't investigate this too closely.
---
* Origin: (1:3634/12.73)

Vince Coen wrote to Rj Clay:

Saturday December 02 2017 04:58, you wrote to me:

So inactive .tic files would be ones that have already been sent,
and at least in more recent versions get automatically cleaed up?
(That was one of concerns as lots of tiny files can really jump up
inode usage...)

The nightly script clears these and files/mail that has been sent out from the outbound directories etc but after the files / mail have been sent

So old files there are a pretty good sign of FTN sessions not
happening preperly or not being connected to the node that the files are for? Easier to see in the ticqueue, since it's a single directory, but relatively easy still to compare against the 'mbout sta' output.

If you are going to use mbse over a previous BBS then you may well also want to adopt all of the various bbs file areas into mbse using mbfile.

There's a separate issue regarding that as all of the public files areas are/were kept in separate, from the Mbse BBS install, directories, and that it
turns out I didn't have a backup of.

So there are a lot of files in the BBS files database that are not actully present. Presumably I can take are of this by putting the files were it thinks
they are but I need to decide which ones to to that for...



Jame

Greetings, Rj Clay
email: admftn@ftn.rocasa.net

--- MBSE BBS v1.0.6.8 (GNU/Linux-i386)
* Origin: ftn.rocasa.net (1:120/544)

Vince Coen wrote to Rj Clay:

Before I forget the current version that sits in the source repo is 1.0.7.4.
While the files area it is 1.0.7.2 the difference being one file see the Changelog

Since I had no real issue with upgrading from even the quite old 0.97 that was running on the old system, I don't really anticipate an issue upgrading it again to the current version. Just haven't been able to get to it...



Jame


Greetings, Rj Clay
email: admftn@ftn.rocasa.net

--- MBSE BBS v1.0.6.8 (GNU/Linux-i386)
* Origin: ftn.rocasa.net (1:120/544)

Hello Rj!

Sunday December 03 2017 10:57, you wrote to me:

If you are going to use mbse over a previous BBS then you may well
also want to adopt all of the various bbs file areas into mbse
using mbfile.

There's a separate issue regarding that as all of the public files
areas are/were kept in separate, from the Mbse BBS install,
directories, and that it turns out I didn't have a backup of.

So there are a lot of files in the BBS files database that are not actully present. Presumably I can take are of this by putting the
files were it thinks they are but I need to decide which ones to to
that for...

That is what the mbfile adopt function is for however if you have all of the files.bbs and 00index you may have other ways of ding it but when I migrated to
mbse I did use the mbfile adopt feature as it was a lot easier even if there was over 300 areas.


Vince

--- Mageia Linux v5.1/Mbse v1.0.7.4/GoldED+/LNX 1.1.501-b20150715
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

Hello Rj!

Sunday December 03 2017 11:07, you wrote to me:

Vince Coen wrote to Rj Clay:

Before I forget the current version that sits in the source repo
is 1.0.7.4. While the files area it is 1.0.7.2 the difference
being one file see the Changelog

Since I had no real issue with upgrading from even the quite old
0.97 that was running on the old system, I don't really anticipate an
issue upgrading it again to the current version. Just haven't been
able to get to it...

As the mbse database has changed over the various versions I suggest you adopt a method of dealing such as :

1. Install the 0.97 version but dont run it.
2. upgrade to the next release and keep doing so where the release notes say change of DB exists. and yes it may well involve doing this a few times.

OR
3. Follw 1. and take a dump of all of the documents for the running system saving the .doc/.pdf file.
4. Using that with the latest version go through setting up the various settings via each menu entry.

Personally I would try the first method.

I seem to recall that the jump using 1.0.6 to 1.0.7 is minimal changes to the DB and it just involves changing if you want to so that can be ignored but .97 to 1.0.6 will have DB upgrades that the setup processes deal with one by one. Again download all of the versions between 97 and 106 and read the README / Changelogs to verify what one's require a DB fix up. The most it would involve a 3 - 4 hours of work and the computer will be doing most if it.

Vince

--- Mageia Linux v5.1/Mbse v1.0.7.4/GoldED+/LNX 1.1.501-b20150715
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)