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)
File "threatsentry.mpy", line 31, in <module>smatch for module mystic_bbs: Thi
ImportError: No module named dateutil.tzstic_bbs has version 1869874165.
On 30 Oct 2019, Nodoka Hanamura said the following...
File "threatsentry.mpy", line 31, in <module>smatch for module mystic_bbs: Thi
ImportError: No module named dateutil.tzstic_bbs has version 18698741
Looks like the .mpy couldn't find the dateutil module. The API error
could be a symptom of this or in addition to it. Hard to tell because these error messages are a bit mangled and missing info.
Looks like the .mpy couldn't find the dateutil module. The API errorThat's what I'm thinking too, for some reason it can't find it, even though I clearly remember running apt-get install as it was shown in the instructions for both of the mpy's prerequsites.
So, just to ask the dumb questions, you know where the dateutil module is located, and are sure that it's your path?
And when you run "which python", you get the 2.7 install?
No luck, even after installing python-dateutil and python-dateutil-tz in pip while running mystic (under sudo, even after trying running chown -R nikki /mystic - running without sudo doesn't let me bind ipv4 ports for some weird reason) It doesn't work and gives the same error as before.
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:
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
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.
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.
Interesting - how did you allow mis to bind to lower ports out ofcuriousity?
I'd love to try this as well.
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 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. :)
Interesting - how did you allow mis to bind to lower ports out of curiousity? I'd love to try this as well.
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.
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.
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.
On Linux:
setcap cap_net_bind_service=+ep /path/to/program
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 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.
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 409 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 43:11:13 |
| Calls: | 8,568 |
| Calls today: | 8 |
| Files: | 13,222 |
| Messages: | 5,928,456 |