Greetings All!


So I have completed the switch to linux with my mystic bbs (from windows) and
I actually just put it online an hour ago. In watching MIS screen I am noticing that all my fidopoll events now end with a RES 127 when they used to end with a RES 0? As far as I can tell seems to be functioning ok, anyone run into this before? Is there anything different about events in linux version that I missed? I checked all my ini files and they are correct (I think)

Hope all of you are well



----
Regards,


Rick Smith (Nitro)

... No honey, I'm not BBSing again - I'm writing a letter to my mother.
--- GoldED+/LNX 1.1.5-b20180707
* Origin: ----> Abacus Sysop Point --->>>>bbs.abon.us:2323 (1:340/202.1)

On 19 Aug 2020 at 02:13p, Rick Smith pondered and said...

So I have completed the switch to linux with my mystic bbs (from
windows) and I actually just put it online an hour ago. In watching MIS screen I am noticing that all my fidopoll events now end with a RES 127 when they used to end with a RES 0? As far as I can tell seems to be functioning ok, anyone run into this before? Is there anything different about events in linux version that I missed? I checked all my ini files and they are correct (I think)

Hi there

It will likely mean the process you are trying to run is failing as it's not being called correctly.

Check you have something like this in your shell line

./fidopoll 21:1/100

Res 0 means success so you definitely want to check into this.

Best, Paul

--- Mystic BBS v1.12 A46 2020/05/28 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)

windows) and I actually just put it online an hour ago. In watching MIS screen I am noticing that all my fidopoll events now end with a RES 127 when they used to end with a RES 0? As far as I can tell seems to be

A 127 code in Linux is the shell saying that it cannot find whatever it is
that is being executed. Its hard to say more without knowing more about the event, but usually if you have something like:

"fidopoll" you'll need to change it to "./fidopoll" in Linux.

I was experimenting with having Mystic automatically add the ./ in Linux but
I can't remember why I didn't do it.

--- Mystic BBS v1.12 A46 2020/08/13 (Windows/64)
* Origin: Sector 7 | Mystic WHQ (1:129/215)

On 19 Aug 2020, g00r00 said the following...

I was experimenting with having Mystic automatically add the ./ in Linux but I can't remember why I didn't do it.

Given what I've seen from FB groups and echos of people making the switch, I don't think you should change it like that. Some people don't understand
what's supposed to be in there, but many don't understand unix paths and
the path variable. I'd say some combination of the following:

1. Have mis know where it's run from and just make everything without an explicit ./ or /mystic path assume the base mystic directory.

2. Expanded instructions in the wiki (or an inline help?) about what should
be happening in those event shell fields.


- Andre

--- Mystic BBS v1.12 A45 2020/02/18 (Raspberry Pi/32)
* Origin: Runaan BBS (1:154/70)

I was experimenting with having Mystic automatically add the ./ in Li but I can't remember why I didn't do it.

1. Have mis know where it's run from and just make everything without an explicit ./ or /mystic path assume the base mystic directory.
2. Expanded instructions in the wiki (or an inline help?) about what should be happening in those event shell fields.

That's already how it works, but ./ is required to specify current directory (even if you're in it).

The issue here is that he has an invalid command in the shell command field. Mystic is properly reporting "this is an invalid command". In this case its not misundertanding the shell field, its a misunderstanding of how Linux works.

When I get around to moving the event documentation out of release notes and onto the Wiki I will note the differences between Windows and Linux to help
out with common mistakes.

--- Mystic BBS v1.12 A46 2020/08/13 (Windows/64)
* Origin: Sector 7 | Mystic WHQ (1:129/215)

On 20 Aug 2020, g00r00 said the following...

That's already how it works, but ./ is required to specify current directory (even if you're in it).

That's true, but I mean have Mystic figure that out for the user, so they
don't have to know that or figure it out.

Maybe the logic to error check what someone puts into the field becomes too complex though. I would say that documentation should take priority over a technical fix like I was suggesting earlier.


- Andre

--- Mystic BBS v1.12 A45 2020/02/18 (Raspberry Pi/32)
* Origin: Runaan BBS (1:154/70)

Hello g00r00,

On Wed Aug 19 2020 21:31:10, g00r00 wrote to Rick Smith:

"fidopoll" you'll need to change it to "./fidopoll" in Linux.

I was experimenting with having Mystic automatically add the ./ in
Linux but I can't remember why I didn't do it.

Because newcomers to linux shouldn't have it *that* easy. Everyone should be able to learn the basics at the very least. Once you learn the basics, running a Mystic server is easy as all get out. Then you can spend time learning the more difficult things. ;)

Regards,
Nick

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

On 21 Aug 2020, Nicholas Boel said the following...

Because newcomers to linux shouldn't have it *that* easy.

Things need to be either intuitive or documented.

Linux has an abundance of documentation and books, so while it's not easy,
it can be understood.

The shell field of the event editor is neither intuitive nor documented. If anything, it's a right of passage.


- Andre

--- Mystic BBS v1.12 A45 2020/02/18 (Raspberry Pi/32)
* Origin: Runaan BBS (1:154/70)

Because newcomers to linux shouldn't have it *that* easy.

Things need to be either intuitive or documented.

The shell field of the event editor is neither intuitive nor documented. If anything, it's a right of passage.

I agree the event stuff needs to be gathered from whatsnews and put onto the Wiki. I'll look into doing that the next time I am on there making edits. But I am curious why you're saying the shell field is not intuitive or documented and what you have in mind to improve it?

When you set the shell field in the editor it tells you right in the editor that the field is the command line that will be executed when the event runs. What more should be said about that? If a person doesn't know what a shell is or a command line is, then they're already in over their heads trying to run a BBS (especially on Linux).

Mystic's event system already has a full screen dedicated to events, their execution times and types, and also tracks potential issues (which is how we knew the event was failing with error 127). A quick Google of "error code 127 linux" gets an explaination in about 30 seconds of effort. Having a view into your events status so you can easily spot an issue and then being able to determine what that error is in about 30 seconds of effort isn't exactly a bad system! Certainly better than most!

The ./ thing specifically is tricky because its not Mystic, its Linux. By trying to explain it I'd be getting into trying to teach people how Linux works. There are times when adding a ./ would break things too. Its a deep rabbit hole to jump into in terms of documenting, and maybe better suited for linking to some how-to Linux guides or something.

--- Mystic BBS v1.12 A46 2020/08/13 (Windows/64)
* Origin: Sector 7 | Mystic WHQ (1:129/215)

On 22 Aug 2020, g00r00 said the following...

I agree the event stuff needs to be gathered from whatsnews and put onto the Wiki. I'll look into doing that the next time I am on there making edits.

It doesn't look like an easy job, for sure. I didn't realize that there was useful info in there that wasn't in the documentation until maybe a week in. Now I just let people know to check there and in the command reference, since there's some useful bits in there too.

But I am curious why you're saying the shell field is not
intuitive or documented and what you have in mind to improve it?

Having a view into your events status so you can easily spot an
issue and then being able to determine what that error is in about 30 seconds of effort isn't exactly a bad system! Certainly better than
most!

The intuitive user menu systems, the interactive messaging system, and the sysop config menus are the reasons why I prefer Mystic over its competitors.
So I 100% agree that the event editor is great.

Here is my thought process as a new user a few weeks ago, which seems common
as I've helped two or three people through the same thing:


1. The shell field isn't intuitive partially because by default it has Windows commands in it, so I think it's already correct and working. (intuitive)

2. Then I find that it's not processing FTN events properly, but the 'mis server' window and logs don't show any errors about it not finding mutil or fidopoll or both. (intuitive)

3. Nothing tells me how it's supposed to look for Windows vs Linux, and
nothing really tells me the process of import/export/fidopoll, and how to troubleshoot. (documentation)

4. So through Mystic Guy videos, I can kind of tell that there are supposed
to be files showing up that when processed disappear. So I determine that if fidopoll runs right, files will show up, and if they're processed by mutil those files will disappear. (documentation)

5. Okay, so there must be something wrong with my shell field. What are the pipes for? Are they actually piping anything, or is it like ';' in Linux?
It's not using & or && like Windows expects, so I'm extra confused. Does it need spaces? Commas? (intuitive and documentation)

6. The mis server window and logs lead me to believe that both comamnds in
the shell field are at least being called, but I'm not totally sure. (intuitive)

7. So maybe it's a path issue. Should I use ./ or a full path. I'll try explicitly calling the path since I can't go wrong with that. (intuitive and documentation).


- Andre

--- Mystic BBS v1.12 A45 2020/02/18 (Raspberry Pi/32)
* Origin: Runaan BBS (1:154/70)

Hello Andre,

On Fri Aug 21 2020 19:42:50, Andre Robitaille wrote to Nicholas Boel:

Linux has an abundance of documentation and books, so while it's not
easy, it can be understood.

The shell field of the event editor is neither intuitive nor
documented. If anything, it's a right of passage.

Does it need to be?

If you were to google "how to execute a binary in Linux" I think your answer would be the first to come up tho. I don't understand why it's Mystic's responsibility to show people that?

Even in Windows, one way to make sure of proper execution is to use the full path to the executable. This also works in Linux and then _doesn't_ require "./" to execute.

Regards,
Nick

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

Hello g00r00,

On Sat Aug 22 2020 00:38:36, g00r00 wrote to Andre Robitaille:

The ./ thing specifically is tricky because its not Mystic, its Linux.
By trying to explain it I'd be getting into trying to teach people how Linux works. There are times when adding a ./ would break things too.
Its a deep rabbit hole to jump into in terms of documenting, and maybe better suited for linking to some how-to Linux guides or something.

Best practice would be to use the complete path to the executable, just like in Windows.

Regards,
Nick

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

On 22 Aug 2020, Nicholas Boel said the following...

Does it need to be?

Of course it does. Always.

Software should always be as intuitive and well-documented as possible. There are zero exceptions to this. Often you can reduce the amound of documentation if the UI is sufficiently intuitive.

I certanily miss the old days where few people had computers, and the ones
who did knew how to use them because they were tinkerers and hackers and whatever. But relying on search engines and other offloading documentation
onto proactive endusers? I'm surprised that this is even considered to
possibly be okay.

- Andre`

--- Mystic BBS v1.12 A45 2020/02/18 (Raspberry Pi/32)
* Origin: Runaan BBS (1:154/70)

It doesn't look like an easy job, for sure. I didn't realize that there was useful info in there that wasn't in the documentation until maybe a week in. Now I just let people know to check there and in the command reference, since there's some useful bits in there too.

My documentation of new features goes into the "whatsnew" file with each build I release, and then into the whatsnew section on the Wiki, and eventually it will find its way into a more organized place on the Wiki.

Its a bad way to do things, mostly because of how infrequently I work on the structured part of the Wiki. The information is out there its just not always easy to find depending on what you're looking for.

Documentation is certainly unintuitive because of that.

1. The shell field isn't intuitive partially because by default it has Windows commands in it, so I think it's already correct and working. (intuitive)

The default event examples are not specific to Windows or anything really, they're just examples. You could use them for any OS Mystic runs on or not use them at all.

2. Then I find that it's not processing FTN events properly, but the 'mis server' window and logs don't show any errors about it not finding mutil or fidopoll or both. (intuitive)

Mystic events log and track previous results of every event it runs. Shell events are listed in the event window with a "time until execution" and when they do execute it shows that its running, shows exactly what commands it is executing, and then shows you the result reported back by the OS. All of that is logged and in the UI.

There is only so much Mystic can track when executing an unknown user configured command line as an event, and it does just about everything it can. Do you see it run on the screen and logs? If so what is the result?

MIS can only show that an event ran, what it tried to run, and if the OS says it ran successfully. If it says it ran successfully then you'd need to look at the logs of the program it ran.

3. Nothing tells me how it's supposed to look for Windows vs Linux, and

The commands for everything in Mystic are the same regardless of OS so there really isn't much to document as far as differences in how Mystic works.

4. So through Mystic Guy videos, I can kind of tell that there are supposed to be files showing up that when processed disappear. So I determine that if fidopoll runs right, files will show up, and if
they're processed by mutil those files will disappear. (documentation)

I am assuming you're watching the YouTube series on how to setup FidoNet network on a Pi. In the video it goes through the various steps and shows log files and what should be in the log files. It pulls for mail manually with fidopoll to show the mail exchange is setup properly. Have you done all of this stuff and did it all work?

If the messy documentation combined with this video series isn't sufficient, then what do you feel should be added to make it better?

5. Okay, so there must be something wrong with my shell field. What are the pipes for? Are they actually piping anything, or is it like ';' in Linux? It's not using & or && like Windows expects, so I'm extra
confused. Does it need spaces? Commas? (intuitive and documentation)

Here is the documentation for the semaphore/shell type pasted from the Wiki. It seems clear enough to me but I suspect you never saw it. Finding it *IS* unintuitive because its tucked away in the WHATSNEW section on the Wiki (I
left an update to TYPE1 out because this message is already getting long)

TYPE1: Semaphore
================
This event type listens for one or more "semaphore" files, and will execute
a command line if one or more of the semaphore files are found. Prior to
executing the command line, MIS will also delete the detected semaphores.

The following options are used for Semaphore type events. Any other
options not mentioned here can be ignored for this type:

Active - If yes this event will be active. Set to No to disable.
Description - This can be any description you want.
Exec Type - This is one of BBS, Shell, or Semaphore
Semaphore - This defines the semaphore filename to "look" for. If
there is no path included, Mystic will automatically look
in the configured semaphore directory. In addition, more
than one semaphore file can be monitored by using a pipe
symbol to separate them (|). For example:

Semaphore: echomail.out|netmail.out

The above example will look for the existance of EITHER
echomail.out or netmail.out in the configured semaphore
directory. If either file is found, the event will remove
the semaphore files and then execute the event.

Semaphore: c:\mybbs\somefile.txt

The above will list for the c:\mybbs\somefile.txt and
trigger the event if it is found.

Shell - This is the command line which will be executed when the
event is triggered. Similar to the Semaphore detection,
this can have one *or more* executions per event each
separated by a pipe. If no path is supplied, MIS will
default to the root Mystic BBS directory. For example:

Shell: domail.bat

The above example will execute domail.bat in the root
Mystic BBS directory.

Shell: mutil export.ini|fidopoll send|mutil import.ini

The above will execute 3 command lines in a row:

mutil export.ini
fidopoll send
mutil import.ini

If we put it all together we can get something like this:

Active: Yes
Description: Send outgoing echomail
Exec Type: Semaphore
Semaphore: echomail.out|netmail.out
Shell: mutil export.ini|fidopoll send|mutil import.ini

The above example wait for echomail or netmail.out, and
execute mutil to export, then fidopoll to send, then
mutil to import any new packets. Completely automated!

TYPE2: Shell
============
This event type executes at a defined time, defined on a weekly schedule.

When the event executes, it will execute the Shell command line. Like the
Semaphore event type, this Shell command can also execute multiple command
lines by separating them with a pipe character (|).

The different between this type and Semaphore is that instead of waiting
for a file, the event is defined by a specific execution time. This is
defined by picking which days of the week the event should execute, and
what time per day it should be ran (in 24-hour format). For example:

Active: Yes
Description: Pack message bases
Exec Type: Shell
Shell: mutil msgpack.ini
Exec Hour: 01
Exec Min: 30

Sun: No Mon: Yes Tue: No Wed: No Thu: No Fri: No Sat: No

The above event would execute once per week, at 1:30am on Monday morning
and execute the command line "mutil msgpack.ini" from the root Mystic BBS
directory.

7. So maybe it's a path issue. Should I use ./ or a full path. I'll try explicitly calling the path since I can't go wrong with that. (intuitive and documentation).

Maybe the documentation could link to some "how to use Linux" tutorials or some stackoverflow question on "what does ./ mean in Linux" and that could be helpful.

There really isn't one answer for this and its not something determined by Mystic. Its determined by your Linux setup, what you have in your path, what you're executing, etc. Mystic just executes what you tell it to execute, its up to you to understand how the OS works and what you need to put in that field. I would guess that you need to put a ./ though.

Thanks for the feedback!

--- Mystic BBS v1.12 A46 2020/08/22 (Windows/64)
* Origin: Sector 7 | Mystic WHQ (1:129/215)

Greetings g00r00!

Answering a msg of <22 Aug 20>, from you to Andre Robitaille, about Re: Switch to linux:

I got everything to work on the pI4 except python a couple python scripts result in mismatch apt errors, so for now just stopped using the script (anipause) I ultimately after 24 hours had to switch back to my windows setup. I realized while everything was polling and running mutil with result 0 the mail was nowhere to be found. I could get netmail back and fourth mostly but no echo mail posted on the pi mystic would go anywhere. all my paths are correct, I even after developing blurry eyes had another sysop ssh in and he was unable to find what it could be.. Not even sure why I am telling you this as I have no idea where to look Ive read everything I can read triple checked every INI file. Possibly I will watch mystic guys pi mystic setup videos and see if there is something I am missing. For now its back on my nuc running windows so no worries.

PS is there a way to resize mystic windows in linux? or rather just have mystic match size of terminal windows?

Hope you are well


----
Regards,


Rick Smith (Nitro)

... BBSing very long distance - from Atascadero, California
--- GoldED+/LNX 1.1.5-b20180707
* Origin: ----> Abacus Sysop Point --->>>>bbs.abon.us:2323 (1:340/202.1)

On 22 Aug 2020, Rick Smith said the following...

Greetings g00r00!

Answering a msg of <22 Aug 20>, from you to Andre Robitaille, about Re: Switch to linux:

This is the guy I was telling you about in the other message base, and the issue he's having. =)

--- Mystic BBS v1.12 A46 2020/06/11 (Linux/64)
* Origin: http://www.throwbackbbs.com -\- meriden, ct -\- (1:142/799)

Hello Andre,

On Sat Aug 22 2020 09:54:56, Andre Robitaille wrote to Nicholas Boel:

Does it need to be?

Of course it does. Always.

Software should always be as intuitive and well-documented as
possible. There are zero exceptions to this. Often you can reduce the amound of documentation if the UI is sufficiently intuitive.

I certanily miss the old days where few people had computers, and the
ones who did knew how to use them because they were tinkerers and
hackers and whatever. But relying on search engines and other
offloading documentation onto proactive endusers? I'm surprised that
this is even considered to possibly be okay.

While I totally get what you're saying, and in many cases you're definitely right. But, *Basic* Linux 101 should probably be known before trying to run servers on it. Don't you think?

Maybe James ASSUMEd that was the case, and originally thought the user of said operating system would know how to execute a shell command. Other than that, it doesn't hurt anything if it was added for those that don't know, I guess. ;)

Regards,
Nick

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