Okay, anyone familiar with Python and ThreatSentry - I need your help.

After installing TS for a pre-login configuration, my BBS is throwing up this error on connection.

sys:1: RuntimeWarning: Python C API version mismatch for module __mysticerror__:
PYTHON ERROR (threatsentry.mpy)13, module __mysticerror__ has version 1869874165
.

File "threatsentry.mpy", line 31, in <module>smatch for module mystic_bbs: Thi
ImportError: No module named dateutil.tzstic_bbs has version 1869874165.


Anyone know how to fix this? I've followed the instructions to the T in installation.asc, but with no luck. I made sure python was enabled in mystic and that the right version was installed, 2.7. I made sure python-dateutil and python-tz are installed.

I'm at a loss here.

Born too late to experience the scene.
Born just in time to see it come back.
Nodoka Hanamura - NeoCincinnati BBS SYSOP - neocinci.bbs.io

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/32)
* Origin: NeoCincinnati BBS (21:2/106)

That's normal and expected - the mis daemon will need to be launched as root in order to bind the TCP ports, but only uses root for this
purpose. After the ports are bound, it will run the daemon using the
user account that owns the mystic directory. You can confirm this by running:

I'm not 100% sure that's the issue discussed here, but if it is, I'm
personally strongly against starting any process as root that should run in userspace. There are two other options. One is to bind to non privileged
ports and then set up your firewall to do port forwarding. This option has
few drawbacks, if any, but you have to open multiple ports on your firewall. Not sure if that matters much. The other option is to allow 'mis' to bind to lower ports. This is the option I use, and I use my bbs user.

I noticed when beginning mis as root, certain environment variables would be screwed up and things like dosemu wouldn't work appropriately. That may be
the problem we're dealing with here.

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: monterey bbs (21:1/168)

On 11-03-19 00:14, ryan wrote to lemonlime <=-

I'm not 100% sure that's the issue discussed here, but if it is, I'm personally strongly against starting any process as root that should

Though starting as root then dropping privileges is an established practice.

run in userspace. There are two other options. One is to bind to non privileged ports and then set up your firewall to do port forwarding.
This option has few drawbacks, if any, but you have to open multiple

One big drawback - what if there's no NAT router? You either have to setup some rules in iptables or put up with non standard ports. Some of us actually have public IPs for their BBSs and there's IPv6 (which is generally public). :)

ports on your firewall. Not sure if that matters much. The other option
is to allow 'mis' to bind to lower ports. This is the option I use, and
I use my bbs user.

I use this option as well these days, mainly because then all my BBS management can be done as the user and not having to switch to root just to start or stop the system. :)

I noticed when beginning mis as root, certain environment variables
would be screwed up and things like dosemu wouldn't work appropriately. That may be the problem we're dealing with here.

Possibly. Another good reason to start as the BBS user. :)


... Early bird gets the worm, but the second mouse gets the cheese
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)

I'm not 100% sure that's the issue discussed here, but if it is, I'm personally strongly against starting any process as root that should run in userspace. There are two other options. One is to bind to non privileged ports and then set up your firewall to do port forwarding.
This option has few drawbacks, if any, but you have to open multiple
ports on your firewall. Not sure if that matters much. The other option
is to allow 'mis' to bind to lower ports. This is the option I use, and
I use my bbs user.

Interesting - how did you allow mis to bind to lower ports out of curiousity? I'd love to try this as well.

I noticed when beginning mis as root, certain environment variables
would be screwed up and things like dosemu wouldn't work appropriately. That may be the problem we're dealing with here.

I've had this problem as well with dosemu and could never get it working
right. It always threw errors about environment variables.

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: Stellar Darkness BBS (21:4/162)

On Sun, 3 Nov 2019 14:55:38 +0000
"lemonlime -> ryan" <0@162.4.21> wrote:

Interesting - how did you allow mis to bind to lower ports out of

curiousity?

I'd love to try this as well.

On Linux:
setcap cap_net_bind_service=+ep /path/to/program

---
* Origin: (21:1/151)

I'm not 100% sure that's the issue discussed here, but if it is, I'm personally strongly against starting any process as root that should

Though starting as root then dropping privileges is an established practice.

Agreed, though most processes that do this don't fork off and run other processes, like python or dosemu. That's where I ran into issues, personally, and why I decided I wasn't a big fan of doing that for a BBS.

run in userspace. There are two other options. One is to bind to non privileged ports and then set up your firewall to do port forwarding. This option has few drawbacks, if any, but you have to open multiple

One big drawback - what if there's no NAT router? You either have to setup some rules in iptables or put up with non standard ports. Some of us actually have public IPs for their BBSs and there's IPv6 (which is generally public). :)

Yep, sorry to make assumptions. I have hosted my BBS on a cloud VPS for so
long I have actually forgotten what it's like to let clients inside your firewall :P Managing stuff with iptables (especially if you use ufw) is
pretty straightforward, though.

ports on your firewall. Not sure if that matters much. The other opti is to allow 'mis' to bind to lower ports. This is the option I use, a I use my bbs user.

I use this option as well these days, mainly because then all my BBS management can be done as the user and not having to switch to root just to start or stop the system. :)

Yep, this is what I do. It streamlines modding, startup/shutdown, etc. It's really the best option and IMO should be part of the mystic docs.

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: monterey bbs (21:1/168)

Interesting - how did you allow mis to bind to lower ports out of curiousity? I'd love to try this as well.

I believe I ran
setcap 'cap_net_bind_service=+ep' /mystic/mis

I reserve the right to be wrong but searching for setcap as a solution will get you moving in the right direction. The drawback here is now mis can do whatever it wants. The alternative could be per-port configuration with something like authbind.

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: monterey bbs (21:1/168)

On 11-03-19 09:50, ryan wrote to Vk3jed <=-

Though starting as root then dropping privileges is an established practice.

Agreed, though most processes that do this don't fork off and run other processes, like python or dosemu. That's where I ran into issues, personally, and why I decided I wasn't a big fan of doing that for a
BBS.

Good point there. :)

Yep, sorry to make assumptions. I have hosted my BBS on a cloud VPS for
so long I have actually forgotten what it's like to let clients inside your firewall :P Managing stuff with iptables (especially if you use
ufw) is pretty straightforward, though.

Well, you're not dealing with NAT either. :)

ports on your firewall. Not sure if that matters much. The other opti is to allow 'mis' to bind to lower ports. This is the option I use, a I use my bbs user.

I use this option as well these days, mainly because then all my BBS management can be done as the user and not having to switch to root just to start or stop the system. :)

Yep, this is what I do. It streamlines modding, startup/shutdown, etc. It's really the best option and IMO should be part of the mystic docs.

I got the method from the Synchronet docs and use it with both SBBS and Mystic. :)


... The shortest distance between two points is under construction.
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)

I believe I ran
setcap 'cap_net_bind_service=+ep' /mystic/mis

I reserve the right to be wrong but searching for setcap as a solution will get you moving in the right direction. The drawback here is now mis can do whatever it wants. The alternative could be per-port
configuration with something like authbind.

Thanks for that! I'm going to give it a shot to see if it resolves some of
the environment variable issues I ran into when executing external programs (like DOSEMU etc).

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: Stellar Darkness BBS (21:4/162)

On Linux:
setcap cap_net_bind_service=+ep /path/to/program

Thanks Oli!

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: Stellar Darkness BBS (21:4/162)

Yep, this is what I do. It streamlines modding, startup/shutdown, etc. It's really the best option and IMO should be part of the mystic docs.

I'd agree - this should be included in the mystic docs, even if just as an alternate option for running mis. I had no idea you could do this :)

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: Stellar Darkness BBS (21:4/162)

I believe I ran
setcap 'cap_net_bind_service=+ep' /mystic/mis

I reserve the right to be wrong but searching for setcap as a solution will get you moving in the right direction. The drawback here is now mis can do whatever it wants. The alternative could be per-port
configuration with something like authbind.

After playing around with it a bit, I decided to re-configure my
Telnet/SSH ports in mis for >1024 instead of using setcap. I then used
iptables to redirect. This worked wonders! All of the issues I had with
dosemu disappeared now that I can start the mis daemon with my non-priv
account instead of launching as root initially. I wish I did this from the beginning :)

Thanks for the info!

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: Stellar Darkness BBS (21:4/162)

On 03 Nov 2019, ryan said the following...

I noticed when beginning mis as root, certain environment variables
would be screwed up and things like dosemu wouldn't work appropriately. That may be the problem we're dealing with here.

I've fixed the problem and MIS is binding ports normally under root, but ThreatSentry is still shitting the bed on startup. I'm probably going to
delete it and wait until I can get around to working on installing a new
linux build on the machine.

Born too late to experience the scene.
Born just in time to see it come back.
Nodoka Hanamura - NeoCincinnati BBS SYSOP - neocinci.bbs.io

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/32)
* Origin: NeoCincinnati BBS - neocinci.bbs.io:23 (21:2/106)