Administrative broadcast message

[wilminator]

Hello,
I was looking for a way to allow an administrative message to be broadcast to everyone online. I was going to use it to announce an hour out that there would be a server reboot.

I reviewed the executer.perl script as suggested, but what it appears to do, as far as I can tell, is provide restore functionality for accounts that lost items or were deleted. I also reviewed the source, and based on what I'm trying to do, editing the existing reboot functions in nice.cpp would have made the code significantly more complicated to do what I want to do.

I decided to add a new Linux signal, USR1, to trigger the read and display of the message.dat file in lib to all users. Because this can only be triggered by signal, this functionality is available to be used from outside the MUD, but only if the operator has shell access on the MUD server.

I also wrote a new script in bin, message, that takes all arguments as input, writes it to the message.dat file, then triggers the USR1 signal on vme.

Example use:
./message "The MUD is looking for donations to by the operators a beer. Please contribute!"
(This message is then sent to all online users)

Files:
bin/message - A shell script that writes it's arguments to lib/message.dat then triggers a USR1 signal to cause vme to send the contents of message.dat to all users. This file has been added to the repository.
lib/message.dat - A file whose contents are sent to all online users when the MUD program is sent a USR1 signal by the OS. This file does not need to exist for vme to run.

Thanks,
Mike

[Seifert69]

Thank you :)

[iamnove]

Not sure if you have looked at the DIL implemented internal MUD commands in the following zones to see if this mirrors some/all or the functionality you're looking at: wiz_broadcast@comm cmd_reboot@commands Broadcast can message all players online and reboot of the MUD can be set for a future time and announces to players (the automatic daily boot also provided 10 minutes notice when enabled). If the extra part this doesn't provide is the ability to initiate it from the system rather than in the MUD it might also be worth considering a DIL approach to solving this problem such as writing to a message file on disk and then having DIL poll for the file on a periodic basis and display message then remove once done. You could also write to the file from DIL as an in-game command so appropriately privileged gods could initiate without requiring server access, and a god could intervene/zap DIL if needed etc. I'm not sure there's any clear principles established for the project but I think where possible the intent has been to move functionality out of the binary and into DIL wherever possible.

…

On Mon, Jul 13, 2020, 2:13 PM Michael Wilmes ***@***.***> wrote: Hello, I was looking for a way to allow an administrative message to be broadcast to everyone online. I was going to use it to announce an hour out that there would be a server reboot. I reviewed the executer.perl script as suggested, but what it appears to do, as far as I can tell, is provide restore functionality for accounts that lost items or were deleted. I also reviewed the source, and based on what I'm trying to do, editing the existing reboot functions in nice.cpp would have made the code significantly more complicated to do what I want to do. I decided to add a new Linux signal, USR1, to trigger the read and display of the message.dat file in lib to all users. Because this can only be triggered by signal, this functionality is available to be used from outside the MUD, but only if the operator has shell access on the MUD server. I also wrote a new script in bin, message, that takes all arguments as input, writes it to the message.dat file, then triggers the USR1 signal on vme. Example use: message "The MUD is looking for donations to by the operators a beer. Please contribute!" (This message is then sent to all online users) Files: bin/message - A shell script that writes it's arguments to lib/message.dat then triggers a USR1 signal to cause vme to send the contents of message.dat to all users. This file has been added to the repository. lib/message.dat - A file whose contents are sent to all online users when the MUD program is sent a USR1 signal by the OS. This file does not need to exist for vme to run. Thanks, Mike ------------------------------ You can view, comment on, or merge this pull request online at: #6 Commit Summary - * Added message_request signal hook to SIGUSR1, which triggers the contents of lib/message.dat to be broadcast to all users. - Converted line from a pointer to a 512 byte char array. - Updated fopen to look in lib directory. - Added missing include. - Added message script to provide a direct means to push a system message into the MUD. - Updated executable property on message. File Changes - *A* vme/bin/message <https://github.com/Seifert69/DikuMUD3/pull/6/files#diff-df17f00a3bb4b300f27caea948f8ee0b> (3) - *M* vme/src/db.h <https://github.com/Seifert69/DikuMUD3/pull/6/files#diff-017cdee6e54b8f77a8cacd01d508ef3e> (1) - *M* vme/src/signals.cpp <https://github.com/Seifert69/DikuMUD3/pull/6/files#diff-0735bb251968326917fd507e3e51b2b1> (31) Patch Links: - https://github.com/Seifert69/DikuMUD3/pull/6.patch - https://github.com/Seifert69/DikuMUD3/pull/6.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGEYWFPCJNBWQXBZIGT73E3R3KCX7ANCNFSM4OYE6BTA> .

[Seifert69]

It's a good idea to expand this to trigger a DIL. On Mon, Jul 13, 2020 at 8:10 AM Damien Davison <notifications@github.com> wrote:

…

Not sure if you have looked at the DIL implemented internal MUD commands in the following zones to see if this mirrors some/all or the functionality you're looking at: ***@***.*** ***@***.*** Broadcast can message all players online and reboot of the MUD can be set for a future time and announces to players (the automatic daily boot also provided 10 minutes notice when enabled). If the extra part this doesn't provide is the ability to initiate it from the system rather than in the MUD it might also be worth considering a DIL approach to solving this problem such as writing to a message file on disk and then having DIL poll for the file on a periodic basis and display message then remove once done. You could also write to the file from DIL as an in-game command so appropriately privileged gods could initiate without requiring server access, and a god could intervene/zap DIL if needed etc. I'm not sure there's any clear principles established for the project but I think where possible the intent has been to move functionality out of the binary and into DIL wherever possible. On Mon, Jul 13, 2020, 2:13 PM Michael Wilmes ***@***.***> wrote: > Hello, > I was looking for a way to allow an administrative message to be broadcast > to everyone online. I was going to use it to announce an hour out that > there would be a server reboot. > > I reviewed the executer.perl script as suggested, but what it appears to > do, as far as I can tell, is provide restore functionality for accounts > that lost items or were deleted. I also reviewed the source, and based on > what I'm trying to do, editing the existing reboot functions in nice.cpp > would have made the code significantly more complicated to do what I want > to do. > > I decided to add a new Linux signal, USR1, to trigger the read and display > of the message.dat file in lib to all users. Because this can only be > triggered by signal, this functionality is available to be used from > outside the MUD, but only if the operator has shell access on the MUD > server. > > I also wrote a new script in bin, message, that takes all arguments as > input, writes it to the message.dat file, then triggers the USR1 signal on > vme. > > Example use: > message "The MUD is looking for donations to by the operators a beer. > Please contribute!" > (This message is then sent to all online users) > > Files: > bin/message - A shell script that writes it's arguments to lib/message.dat > then triggers a USR1 signal to cause vme to send the contents of > message.dat to all users. This file has been added to the repository. > lib/message.dat - A file whose contents are sent to all online users when > the MUD program is sent a USR1 signal by the OS. This file does not need to > exist for vme to run. > > Thanks, > Mike > ------------------------------ > You can view, comment on, or merge this pull request online at: > > #6 > Commit Summary > > - * Added message_request signal hook to SIGUSR1, which triggers the > contents of lib/message.dat to be broadcast to all users. > - Converted line from a pointer to a 512 byte char array. > - Updated fopen to look in lib directory. > - Added missing include. > - Added message script to provide a direct means to push a system > message into the MUD. > - Updated executable property on message. > > File Changes > > - *A* vme/bin/message > < https://github.com/Seifert69/DikuMUD3/pull/6/files#diff-df17f00a3bb4b300f27caea948f8ee0b > > (3) > - *M* vme/src/db.h > < https://github.com/Seifert69/DikuMUD3/pull/6/files#diff-017cdee6e54b8f77a8cacd01d508ef3e > > (1) > - *M* vme/src/signals.cpp > < https://github.com/Seifert69/DikuMUD3/pull/6/files#diff-0735bb251968326917fd507e3e51b2b1 > > (31) > > Patch Links: > > - https://github.com/Seifert69/DikuMUD3/pull/6.patch > - https://github.com/Seifert69/DikuMUD3/pull/6.diff > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#6>, or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AGEYWFPCJNBWQXBZIGT73E3R3KCX7ANCNFSM4OYE6BTA > > . > — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOOOMXWIJJV7BMHB7F4MS73R3KQMTANCNFSM4OYE6BTA> .

[wilminator]

Because I'm new to the source, can you expand on what DIL is?

[iamnove]

The doco has some good intros, can start here and look at the DIL sections: https://github.com/Seifert69/DikuMUD3/wiki Quick explanation though, it's a scripting language and interpreter for building programs in the MUD. You can write and compile them in zones and load them up at boot without changing the binary. It can be used to make interactive NPCs, objects etc, write new commands, trigger events, built new in game functionality etc, and doesn't require modifying the actual game engine in source. When you compiled the .zon files separate to the main source you were compiling the zones (rooms, NPCs, objects) and all the DIL programs within them too.

…

On Wed, Jul 22, 2020, 11:02 AM Michael Wilmes ***@***.***> wrote: Because I'm new to the source, can you expand on what DIL is? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGEYWFJT6QOVAV6IKEC2SGTR4Y3A7ANCNFSM4OYE6BTA> .

[wilminator]

Thanks for that. This now feels like a step down from drinking from a fire hose, so I'll manage.

The process that I was working with was an automated process to stop the MUD and essentially recompile and restart. It was not my desire (per se) to schedule the mud to reboot. I'm working out of Docker and have to rely on SIGKILL or the like to stop the mud when done, otherwise I need to have my rebuild scripts wait on a cron for the mud to kill itself.

Now what I have done is introduce a mechanism that an outside program can use to invoke a command on the MUD. I can go ahead and update the command to directly invoke a DIL, but to press my luck, would it be a more useful feature to have the routine execute a specific DIL supplied by the file? Yes, I'm aware of the risks, so maybe limit it to a new zon file dedicated to being invoked externally?

[iamnove]

I like that idea, sounds good to me. In my mind there's not much issue trusting security of things from the server side, even specifying any zones DIL template, if someone is abusing DIL on the MUD from the command line then there's probably bigger security problems than which DIL they can execute. The concern I touched on earlier was more like what happens if someone sets something up from the command line, like a script/cron job, that ends up out of control or stuck in a loop and none of the MUDs admins can stop it without command line access (server guy is asleep etc.). When a DIL that's meant to run forever (i.e. loops and sleeps) goes wrong in game there's a dilzap command to stop it running, so in terms of risks the "nice to have" I'd be looking at is whether there's an equivalent way to stop a DIL that's being triggered from outside, dilzap won't help because you would have to zap it in the split second between the signal and when the DIL starts so need a way to maybe disable the feature temporarily or block a certain DIL from being run etc. Probably not critical but could prevent a disaster :)

…

On Wed, Jul 22, 2020, 2:08 PM Michael Wilmes ***@***.***> wrote: Thanks for that. This now feels like a step down from drinking from a fire hose, so I'll manage. The process that I was working with was an automated process to stop the MUD and essentially recompile and restart. It was not my desire (per se) to schedule the mud to reboot. I'm working out of Docker and have to rely on SIGKILL or the like to stop the mud when done, otherwise I need to have my rebuild scripts wait on a cron for the mud to kill itself. Now what I have done is introduce a mechanism that an outside program can use to invoke a command on the MUD. I can go ahead and update the command to directly invoke a DIL, but to press my luck, would it be a more useful feature to have the routine execute a specific DIL supplied by the file? Yes, I'm aware of the risks, so maybe limit it to a new zon file dedicated to being invoked externally? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGEYWFMD6MFDNFB2LL5ZSFTR4ZQ2DANCNFSM4OYE6BTA> .

[Seifert69]

MIchael, We can easily give you a DIL in e.g. the commands zone. reboot (cmd_reboot) is already in there. So you could just build on that code. Drop me a mail if you want me to help. --M

…

On Wed, Jul 22, 2020 at 6:08 AM Michael Wilmes ***@***.***> wrote: Thanks for that. This now feels like a step down from drinking from a fire hose, so I'll manage. The process that I was working with was an automated process to stop the MUD and essentially recompile and restart. It was not my desire (per se) to schedule the mud to reboot. I'm working out of Docker and have to rely on SIGKILL or the like to stop the mud when done, otherwise I need to have my rebuild scripts wait on a cron for the mud to kill itself. Now what I have done is introduce a mechanism that an outside program can use to invoke a command on the MUD. I can go ahead and update the command to directly invoke a DIL, but to press my luck, would it be a more useful feature to have the routine execute a specific DIL supplied by the file? Yes, I'm aware of the risks, so maybe limit it to a new zon file dedicated to being invoked externally? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOOOMXQJKAAA7A4LBOYUC23R4ZQ2DANCNFSM4OYE6BTA> .

[wilminator]

@iamnove That makes sense on both counts. So I'm thinking adding a DIL command that can be used to set the minimum time between responding to a signal triggered command, with the default specified in the etc/server.cfg file. I think a reasonable default is 600 seconds; this is open to discussion. I will also look expanding this to beyond messaging later; just keying on one command for now is low hanging fruit and I don't want to commit to more than I have time for.

@Seifert69 Thanks for the offer. I'm thinking for now to have the signal trigger call a new DIL that checks if it is able to trigger, and if so passes the string on as a call to wiz_broadcast. Later we can look into expanding that through the zone file to allow other calls, such as shutdown (that's actually what I need for my project), but this will at least complete the conversion of the C++ code to use a DIL.

Thanks,
Mike