Hello Folks,

I have recently upgraded my raspberry pi to A48 prealpha, and started
running a few tests.

All seems to be fine, but for some reason netmails are not being imported.

Checking the MUTIL logs I get the following error message:

----------------- MUTIL v1.12 A48 2022/02/09 Fri, Feb 11 2022 (loglevel 3)
+ Feb 11 00:40:33 Startup using inbound.ini
- Feb 11 00:40:33 EXEC ImportEchoMail
+ Feb 11 00:40:33 Process: Importing EchoMail
+ Feb 11 00:40:33 Waiting for BUSY nodes
! Feb 11 00:40:33 Import from /home/pi/mystic/echomail/in/
! Feb 11 00:40:36 068ee04c.pkt is not a valid PKT

Looking upon 068ee04c.pkt, it looks like a regular netmail to me. I can
send netmails normally (areafix requests are being processed), but each
and every netmail I receive gets the same fate, be it Areafix responses
or netmails from friends.

I checked the inbound.ini file and could not see anything. Is there any
point that I might be overlooking?

--
_
..-----________________--_ ________.--'-`--._____ Flavio Bessa \____==================_) \_'===================` 4:801/188
_,--___.-|__|-.______|=====/ `---' fcbessa@gmail.com
`---------._ ~~~~~| Rio de Janeiro
`-._ - - - ,' Brasil
\_____,-' Visit Zone4 Website at: https://fido.bbs.docksud.com.ar/wiki/doku.php?id=fidonet:nodos
--- Mystic BBS/NNTP v1.12 A48 2022/02/09 (Raspberry Pi/32)
* Origin: Epimetheus - Experimental System (4:801/195)

Flavio,

I am getting the same thing. Hopefully someone can point us to the right direction for a fix.

Tim

----------------- MUTIL v1.12 A48 2022/04/03 Mon, Dec 12 2022 (loglevel 3)
+ Dec 12 00:15:11 Startup using mailin.ini
- Dec 12 00:15:11 EXEC FileToss
- Dec 12 00:15:11 EXEC ImportEchoMail
+ Dec 12 00:15:11 Process: Toss FDN/TIC Files
+ Dec 12 00:15:11 Waiting for BUSY nodes
+ Dec 12 00:15:11 Scanning Hatches
+ Dec 12 00:15:11 Results: 0 import, 0 toss, 0 hatch, 0 bad in 0.02s
+ Dec 12 00:15:11 Process: Importing EchoMail
! Dec 12 00:15:14 637c4616.pkt is not a valid PKT
! Dec 12 00:15:18 637c4625.pkt is not a valid PKT
! Dec 12 00:15:18 Cannot find arctype for 71211085.12.mo0; skipping

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

5Flavio,

I am getting the same thing. Hopefully someone can point us to the right direction for a fix.

Tim

----------------- MUTIL v1.12 A48 2022/04/03 Mon, Dec 12 2022 (loglevel 3)
+ Dec 12 00:15:11 Startup using mailin.ini
- Dec 12 00:15:11 EXEC FileToss
- Dec 12 00:15:11 EXEC ImportEchoMail
+ Dec 12 00:15:11 Process: Toss FDN/TIC Files
+ Dec 12 00:15:11 Waiting for BUSY nodes
+ Dec 12 00:15:11 Scanning Hatches
+ Dec 12 00:15:11 Results: 0 import, 0 toss, 0 hatch, 0 bad in 0.02s
+ Dec 12 00:15:11 Process: Importing EchoMail
! Dec 12 00:15:14 637c4616.pkt is not a valid PKT
! Dec 12 00:15:18 637c4625.pkt is not a valid PKT
! Dec 12 00:15:18 Cannot find arctype for 71211085.12.mo0; skipping

It could be a zero length packet
JD
--- AfterShock/Android 1.6.8
* Origin: FireCat Mobile (4:920/1.1)

Hello Tim,

On Tue Dec 13 2022 13:50:38, you wrote to All:

Flavio,

I am getting the same thing. Hopefully someone can point us to the
right direction for a fix.

12 00:15:18 Cannot find arctype for 71211085.12.mo0; skipping

"arctype" would lead me to believe you don't have zip/unzip installed or setup correctly in Mystic's configuration?

Regards,
Nick

... "Take my advice, I don't use it anyway."
--- GoldED+/LNX 1.1.5-b20220504
* Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)

On 15 Dec 2022 at 06:00p, Nicholas Boel pondered and said...

12 00:15:18 Cannot find arctype for 71211085.12.mo0; skipping

"arctype" would lead me to believe you don't have zip/unzip installed or setup correctly in Mystic's configuration?

yep I think you're on the right path with this one Nick.

this one is I think because the system has had to rename the zipped packet and you have a filename.morename.extn when it should be filename.extn

suggest rename this one to 71211085.mo0 (assuming sysop does not have one there with the same name in their inbound dir already) then try to re-run the import, but also check you have zip and unzip installed.

Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

--- Mystic BBS v1.12 A47 2021/12/24 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)

On Thursday, December 15, 2022 at 10:20:13 PM UTC-5, Paul Hayton wrote:

On 15 Dec 2022 at 06:00p, Nicholas Boel pondered and said...

12 00:15:18 Cannot find arctype for 71211085.12.mo0; skipping

"arctype" would lead me to believe you don't have zip/unzip installed or setup correctly in Mystic's configuration?

yep I think you're on the right path with this one Nick.

this one is I think because the system has had to rename the zipped packet and
you have a filename.morename.extn when it should be filename.extn

suggest rename this one to 71211085.mo0 (assuming sysop does not have one there
with the same name in their inbound dir already) then try to re-run the import,
but also check you have zip and unzip installed.

Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

Update: I did have zip/unzip installed and was able to verify that it would run from the command line as the sysop user. Also, renaming did not help.

I am running Mystic A48 on Linux Mint 20.3 Cinnamon v 5.2.7. The problem is due to the Mystic folder/file permission settings. When I change the owner and group of the Mystic directories and files to my sysop user/group, I have to run mis as sudo for
it to allow IP connectivity. Then when running mutil, the zip extraction does not work nor does it recognize the pkt files, even if I manually extract them. I tried then setting the mystic application executable files with root as the owner along with
the echomail directory and files. This did not work either no change in log errors.

Finally, I recursively changed the owner of the Mystic directory and files to root leaving the sysop group unchanged. This worked, no errors. I now am trying to determine what the correct permission settings for the directories and folders should be so
that I can run Mystic as the sysop user as the owner and group so that root is not exposed. Is there a way to give the sysop user permissions to the ethernet ports so Mystic can use the IP ports when running as the sysop user?

Gandalf

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Finally, I recursively changed the owner of the Mystic directory and
files to root leaving the sysop group unchanged. This worked, no
errors. I now am trying to determine what the correct permission
settings for the directories and folders should be so
that I can run Mystic as the sysop user as the owner and group so that root is not exposed. Is there a way to give the sysop user permissions
to the ethernet ports so Mystic can use the IP ports when running as the sysop user?

Your files should always be owned by the user and never root. So the chown -R user:user /mystic is the right approach to take, which it sounds like you've done.

You can set Linux to allow binding on ports less than 1024 if you want to. Google is your friend there or maybe someone here can comment more on this method? It probably should be a topic on the Wiki if its not.

You can also port forward port 23 to port 2323 for example and have Mystic listening on that port.

You can also run "sudo ./mis server" and Mystic will change from root user to the owner of the binaries, after it binds the ports.

To see the latter in action you can start with "sudo ./mis server" and then telnet in. Export a message and while you're at the protocol selection prompt, look in the node's temp directory at the exported message. It will be owned by the BBS user that owns mystic and not root, even though you started the service as root.

... Help! I can't find the "ANY" key.

--- Mystic BBS v1.12 A49 2023/01/17 (Windows/64)
* Origin: Sector 7 * Mystic WHQ (1:129/215)

Finally, I recursively changed the owner of the Mystic directory and files to root leaving the sysop group unchanged. This worked, no errors. I now am trying to determine what the correct permission settings for the directories and folders should be so that I can run Mystic as the sysop user as the owner

< and group so that root is not exposed. Is there a way to give the sysop user

permissions to the ethernet ports so Mystic can use the IP ports when
running as the sysop user?

I use setcap here to give a server access to ports below 1024.

You need to be root (or use sudo) to run this command.

sudo setcap 'cap_net_bind_service=+ep' /mystic/mis

You can then use getcap to check that mis has the permisions to open those ports. There is a write here on the synchronet wiki.

https://wiki.synchro.net/howto:linux_non-root

It talks about this and other methods.

If you happen to run mis or mutil as root you can end up with these kind of permissions issues so best not to do that. :)

--- BBBS/Li6 v4.10 Toy-6
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

On Wednesday, January 18, 2023 at 4:20:16 AM UTC-5, Al wrote:

Finally, I recursively changed the owner of the Mystic directory and files to
root leaving the sysop group unchanged. This worked, no errors. I now am trying to determine what the correct permission settings for the directories
and folders should be so that I can run Mystic as the sysop user as the owner

< and group so that root is not exposed. Is there a way to give the sysop user

permissions to the ethernet ports so Mystic can use the IP ports when running as the sysop user?

I use setcap here to give a server access to ports below 1024.

You need to be root (or use sudo) to run this command.

sudo setcap 'cap_net_bind_service=+ep' /mystic/mis

You can then use getcap to check that mis has the permisions to open those ports. There is a write here on the synchronet wiki.

https://wiki.synchro.net/howto:linux_non-root

It talks about this and other methods.

If you happen to run mis or mutil as root you can end up with these kind of permissions issues so best not to do that. :)

Thank you g00r00 and Al. I appreciate your help and have it working except nodespy.

With /mystic owner as user:user and running mis with "sudo ./mis server", I did see in the node's temp directory that the exported message was owned by the BBS user that owns mystic and not root. However, I received the errors in the log, "Cannot find
arctype" and "is not a valid PKT".

After I ran "sudo setcap 'cap_net_bind_service=+ep' /mystic/mis" as suggested by Al, I could start mystic running with "./mis server" and binkp and telnet was able to bind to IPV4. Mutil is now able to run without errors! This is with /mystic owner as
user:user not root:user.

Success! Thank you!

The only issue left is nodespy. When I run nodespy with or without sudo, it is unable to establish a snoop session. Do you have any suggestions to get this to work?

Gandalf

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

One more thing I tried was to chown nodespy* to root then run it. This got rid of the "unable to establish a snoop session" error; it shows the action bar at the bottom, but a blank black screen (the ascii/ansi screens do not display), and on the client
end, the smoothness is gone. The screens display delayed in chunks of data instead of a smooth stream.

Gandalf
"It's a dangerous business, Frodo, running a Mystic BBS. You install it to a Linux OS, and if you don't keep your permissions correct, there's no knowing what it might be swept off to."

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

One more thing I tried was to chown nodespy* to root then run it. This got rid of the "unable to establish a snoop session" error; it shows the action bar at the bottom, but a blank black screen (the ascii/ansi
screens do not display), and on the client
end, the smoothness is gone. The screens display delayed in chunks of data instead of a smooth stream.

It certainly seems like you have permissions issues causing these problems.

What I would do is chown everything back to your BBS user and start from there. There is no need to ever set anything to root or use root. When your BBS is completely shutdown run "sudo ./mis killbusy

When you do set root ownership or run as root user, any files it touches is going to now be owned by root. This is going to break things across the board.

I can't comment on it slowing down but I will do some testing here to see if I can reproduce it and clean it up. When you snoop it is doing more by sending data to more places, so it will require more processing power while snooping. But I wouldn't think it'd be all that noticable to a remote user. What are you running it on? Maybe if its a Pi 1 or Zero or something it but outside that I wouldn't think there would be a dramatic performance hit. I'll check into it!

I will also change NodeSpy to change the root user like the rest of things do, so that you'll be able to run it as "sudo ./nodespy" without causing any issues in the future.

... The seminar on time travel will be held two weeks ago

--- Mystic BBS v1.12 A49 2023/01/17 (Windows/64)
* Origin: Sector 7 * Mystic WHQ (1:129/215)

Eureka! I found the permission issue. My Mystic user was not a member of the Mystic user group that I had created. As soon as I added the user to the group, everything works as you said with owner:group as user:user.

I think the slowdown on the client displaying the menus was due to running nodespy with root as owner, but since root was not the owner or group of the Mystic data menu display files, it was introducing latency when nodespy tried to read/display them.

That to say, there is nothing wrong with Mystic.

So, to summarize, my issues of Mystic A48 running on Linux Mint 20.3 Cinnamon v5.2.7:
1. Mystic user as owner but not a member of the group that has ownership - mutil log errors "is not a valid PKT" and "Cannot find arctype for". Nodespy unable to establish a snoop session.
2. Mystic mis server unable to access ports below 1024:
Run this command as root (or use sudo):
sudo setcap 'cap_net_bind_service=+ep' /mystic/mis

Thank you so much for your help g00r00 and Al. I appreciate it!

Gandalf
"Keep it Mystic, Keep the user a member of the proper group and it will be safe!"

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Eureka! I found the permission issue. My Mystic user was not a member
of the Mystic user group that I had created. As soon as I added the
user to the group, everything works as you said with owner:group as user:user.

Thats great to hear and thanks for following up to let me know!

That to say, there is nothing wrong with Mystic.

Even better news! :)

... THE fIRST sTEP iS tO tAKE oFF tHE cAPS lOCK

--- Mystic BBS v1.12 A49 2023/01/17 (Windows/64)
* Origin: Sector 7 * Mystic WHQ (1:129/215)