Differences

This shows you the differences between two versions of the page.

--- systemd-bpq-telnet-application [2026/02/06 01:30] – ve3qbz
+++ systemd-bpq-telnet-application [2026/02/06 02:11] (current) – ve3qbz
@@ Line 1: / Line 1: @@
-In [[simple-bpq-telnet-application|Creating a simple telnet application for BPQ]] , we describe how to write a simple telnet application that is started by systemd as a daemon, accepts telnet connections to a port, and reads/writes data to that port.  The tutorial also covers how to add this application to BPQ as a command, and have BPQ initiate the telnet connection to the daemon.
+In [[simple-bpq-telnet-application|Creating a simple telnet application for BPQ]] , we describe how to write a simple telnet application that is started by systemd as a service, accepts telnet connections to a port, and reads/writes data to that port.  The tutorial also covers how to add this application to BPQ as a command, and have BPQ initiate the telnet connection to the service.
-In this tutorial, we will demonstrate an alternative approach to telnet-enabling a simple terminal based application for access via BPQ that does not require adding network code to the application - we get all of our network I/O for free courtesy of the systemd socket trigger.
+In this tutorial, we will demonstrate an alternative approach to telnet-enabling a simple terminal based application for access via BPQ that does not require adding network code to the application - we get all of our network I/O for free courtesy of the systemd socket trigger, and our application can simply read and write from standard I/O as if executing at on a normal terminal.
-Our sample application for this tutorial is a WALL command, that allows visitors to the BPQ node to view and leave simple posts on a virtual wall.  The application was written by xxxxx and the source code is available here:
+Our sample application for this tutorial is a WALL command, that allows visitors to the BPQ node to view and leave simple posts on a virtual wall.  The application was written by xxxxx and the source code is available here: xxxx link to Daria's github and website for proper attribution
-This is the code for our WALL application.  Examine this code briefly, and note that all the I/O is simple console input/output - there is no code to bind to a network port, handle incoming connections, manage session state, deal with multiplexing, etc.  Simple standard I/O is all we need.
+This is the code for our WALL application.  Examine this code briefly, and note that all the I/O is simple console input/output - there is no code to bind to a network port, handle incoming connections, manage session state, deal with multiplexing, etc.  Simple standard I/O is all we need, and systemd takes care of all the rest.
-Save this python file wherever you want it to reside on your filesystem; make sure that it is accessible by whatever account you want it to launch under.  Creating, and securing, a service account for this application is beyond the scope of this tutorial.
+Save this python file wherever you want it to reside on your filesystem; making sure that it is accessible by whatever account you want it to launch under.  Creating, and securing, a service account for this application is beyond the scope of this tutorial.
 <code>
@@ Line 161: / Line 161: @@
 </code>
-Next, we need to define a systemd service template for the WALL script.  This file will be named wall@.service, and the @ is important - the @ tells systemd that multiple instances of this service can be launched (ie. that it is a template for multiple service instances, not a singular service).  Without the @ in the filename, systemd would only support a single connection at a time, since a second concurrent connection would not result in a second instance of the service being triggered (which might, in itself, be desired, if your particular application can only support a single session at a time for whatever reason)
+Next, we need to define a systemd service template for the WALL script.  This file will be named wall@.service, and the @ is important - the @ tells systemd that multiple instances of this service can be launched (ie. that it is a template for multiple service instances, not a singular service).  Without the @ in the filename, systemd would only support a single connection at a time, since a second concurrent connection would not result in a second instance of the service being triggered (which might, in itself, be desired, if your particular application can only support a single session at a time for whatever reason).
+Be sure to customize the path, user, and group that the service will launch as appropriate for your system.
 <code>
@@ Line 174: / Line 176: @@
 </code>
-Next, we define a trigger for this service template
+Next, we define a socket trigger for this service template - this is the trigger that will launch the service.
 <code>
@@ Line 188: / Line 190: @@
 </code>
-These two files are placed in /etc/systemd/system, and we request systemd to reload configuration by issuing the systemctl daemon-reload command
+These two files are placed in /etc/systemd/system, and we request systemd to reload configuration by issuing the <code>systemctl daemon-reload command</code>
-At this point, we have three items:
+At this point, we have accomplished the following:
-- we have a python script
+  * we have a python script
-- we've defined that python script as a systemd service template, allowing multiple instances of the service to be launched concurrently, and to redirect Standard Input to a socket
+  * we've defined that python script as a systemd service template, allowing multiple instances of the service to be launched concurrently, and to redirect the service's standard input to a socket
-- we've defined a systemd socket trigger, that listens on port 8016 for connections.  On connection, it will launch the service, and connect the service's standard input to the socket connection that has been established
+  * we've defined a systemd socket trigger, that listens on port 8016 for connections.  On connection, it will launch a copy of the service template, and connect the resulting service's standard input to the socket connection that has been established
-You can test that this all works by executing telnet localhost 8016 - you should get connected to the service.  NOTE that WALL expects BPQ to pass your callsign in as the first line of input; to continue to test interactively, enter your callsign and hit enter, and
+You can test that this all works by executing telnet localhost 8016 - you should get connected to the service.  NOTE that WALL expects BPQ to pass your callsign in as the first line of input; to continue to test interactively, enter your callsign and hit enter - the WALL application will then continue to execute, displaying the wall contents and waiting for input.
+TO BE COMPLETED:
+explain this more fully.
+But for completeness sake, look at application #4 here as a sample of what to place in bpq32.cfg to add the WALL command to your node.  Other than setting the application number appropriately (it should increment from the existing ones), all of the other parameters on the line can be left as is for any linbpq setup.
+Once you've done this, you can test the WALL application again, but from your BPQ node this time, instead of telneting directly to it.
+<code>
+;*****************************************************;
+;                                                     ;
+;*******************  Applications  ******************;
+;1    2         3       4     5      6        7       ;
+;#,BPQ CMD,BBS CMD EXE,CALL,ALIAS,QUALITY,ADD'L CMD   ;
+APPLICATION 1,BBS,,VE3QBZ-1,,191;
+APPLICATION 2,CHAT,,VE3QBZ-4,SCRCHT,191;
+APPLICATION 3,K2K,ATT 2 192.168.1.2 8015 TELNET,VE3QBZ,,0;
+APPLICATION 4,WALL,C 2 HOST 1 S,N0CALL-14,,0;
+APPLICATION 5,IRC,C 2 HOST 2 S
+</code>