Hello All!

I am sending file to a downlink that for reasons only he knows is then sending them back to me.

He is set to only receive them so mbse rejects them BUT it leave them in the var/inbound and does not move them to var/badtic

OR have I a incorrect setting somewhere?

Running 1.0.4 but I guess my tag line shows that :)


Vince

--- Mageia Linux v4/Mbse v1.0.4/GoldED+/LNX 1.1.5-b20130910
* Origin: Air Applewood, The Linux Gateway to the UK (2:250/1)

Hello Vince!

Sunday March 15 2015 17:00, Vince Coen wrote to All:

I am sending file to a downlink that for reasons only he knows is then sending them back to me.

He is set to only receive them so mbse rejects them BUT it leave them
in the var/inbound and does not move them to var/badtic

OR have I a incorrect setting somewhere?

When I have a few moments I'll look at the .TIC processing code and see if I can figure out your issue. Nothing has changed in that regard between 1.0.4 and 1.0.5, so I should be able to reproduce it fairly easily if there is a bug.

Andrew

---
* Origin: Bits & Bytes BBS * V.Everything! * 860/535-4284 (1:320/119)

Hello Andrew!

Monday March 16 2015 09:47, you wrote to me:

I am sending file to a downlink that for reasons only he knows is
then sending them back to me.

He is set to only receive them so mbse rejects them BUT it leave
them in the var/inbound and does not move them to var/badtic

OR have I a incorrect setting somewhere?

When I have a few moments I'll look at the .TIC processing code and
see if I can figure out your issue. Nothing has changed in that
regard between 1.0.4 and 1.0.5, so I should be able to reproduce it
fairly easily if there is a bug.

Using v1.0.4, and I suspect it has been present way before 0.92 :(

He is the first downlink who can not set up his system to prevent it (or does not know how to) so making sure mbse deals with it is the next best solution.

If you have the time? can you take a look at the way mbse deals with setting up
or amending a users password (both new and existing)?

On my system, since changing from Mandriva 2011 (and previous versions) to Mageia v4 (and v3) when a new user telnet's in s/he can only get as far as entering a password then it fails by saying that the file (shadow) is busy.

I suspect that the procedure is out of date for modern Linux kernels and password procedures etc. This stops my system from accepting any new users or allowing an existing one to modify their password, not that I would assume that
my system would be swamped with new users :)

It does get as far as setting up new users home directory, Linux user account then fails to continue with any further processing in the matter including setting up the account in mbse itself.

I did take a look at the code and did a dirty change by creating a dummy passwd
of 12345 but did not make much of an improvement however I do not recall continue to play with just the Linux account setup to include the password but that does not fix the problem if you cannot change it at any point later.
So a silly test really.


Vince

--- Mageia Linux v4/Mbse v1.0.4/GoldED+/LNX 1.1.5-b20130910
* Origin: Air Applewood, The Linux Gateway to the UK (2:250/1)

Hello Vince!

Monday March 16 2015 16:53, Vince Coen wrote to Andrew Leary:

If you have the time? can you take a look at the way mbse deals with setting up or amending a users password (both new and existing)?

On my system, since changing from Mandriva 2011 (and previous
versions) to Mageia v4 (and v3) when a new user telnet's in s/he can
only get as far as entering a password then it fails by saying that
the file (shadow) is busy.

I think this is something specific to Mageia, because it works fine on other distributions, including Debian, Ubuntu, and Slackware. I would have to try setting up a test system on Mageia to see if I can sort that out.

Andrew

---
* Origin: Bits & Bytes BBS * V.Everything! * 860/535-4284 (1:320/119)

Hello Andrew!

Tuesday March 17 2015 05:04, you wrote to me:

Hello Vince!

Monday March 16 2015 16:53, Vince Coen wrote to Andrew Leary:

If you have the time? can you take a look at the way mbse deals
with setting up or amending a users password (both new and
existing)?

On my system, since changing from Mandriva 2011 (and previous
versions) to Mageia v4 (and v3) when a new user telnet's in s/he
can only get as far as entering a password then it fails by
saying that the file (shadow) is busy.

I think this is something specific to Mageia, because it works fine on
other distributions, including Debian, Ubuntu, and Slackware. I would
have to try setting up a test system on Mageia to see if I can sort
that out.

It may well be the way mbse sets the password that conflicts but I could not see it
when I looked at the code but I am hardly current with C and may have missed some
odd coding but it does 'assume' specific working that may be out of date with current kernels and password processing.

Most odd !


Vince

--- Mageia Linux v4/Mbse v1.0.4/GoldED+/LNX 1.1.5-b20130910
* Origin: Air Applewood, The Linux Gateway to the UK (2:250/1)

Hello All,

I recently discovered that for some reason, uncompressed mail packets are not being tossed in upon receipt and are instead being tossed in much later in queue. This does not seem to affect compressed mail packets. The mail IS tossing but very slowly. So I am going to set up a MBSE test system that is non-production and we're going to debug this. This is the same issue that popped up the last time with my using MBSE (and why, out of frustration, I switched back to my OS/2 set up). This time around I'm going to stick to MBSE and figure out why it's acting this way with uncompressed mail packets. I have two Fidonet links that use uncompressed packets and it's only the mail from these two links that are affected.

-- Sean

... When my phone battery died, I was angry and needed to find an outlet.
--- GoldED+/LNX 1.1.5-b20180707
* Origin: Outpost BBS * Johnson City, TN (1:18/200)

Hello Sean!

Monday February 14 2022 08:14, you wrote to All:

Hello All,

I recently discovered that for some reason, uncompressed mail packets
are not being tossed in upon receipt and are instead being tossed in
much later in queue. This does not seem to affect compressed mail
packets. The mail IS tossing but very slowly. So I am going to set
up a MBSE test system that is non-production and we're going to debug
this. This is the same issue that popped up the last time with my
using MBSE (and why, out of frustration, I switched back to my OS/2
set up). This time around I'm going to stick to MBSE and figure out
why it's acting this way with uncompressed mail packets. I have two
Fidonet links that use uncompressed packets and it's only the mail
from these two links that are affected.

I had this last month or so, Check in the system.log what processes are running around the same time that the packets arrive.

I 'think' that it was to do with an instance of the tosser running when the packet arrives so they get ignored until the next time it runs.

Of course my memory might be wrong :)

It has not happened this month but was to do with running more than one instance of golded at the same time so when exiting it sets a semophore up while the other instance is still running.

I am now trying to avoid having more than one instance of golded running.
This was because I was responding within an area but needed to look at another message for details etc.

Vincent
--- Mageia Linux v8 X64/Mbse v1.0.7.24/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)