• Re: Linux and DOS Doors

    From Gryphon@21:2/110 to Nazferiti on Fri Oct 16 06:55:14 2020
    133
    On 05 May 2020, Nazferiti inked down this thought...

    Been running a Win32 version of Mystic for about 45 days now and have
    got a lot of things sorted out, but there are limits to what I can do running on a 32-bit version of Windows 2008 Server.

    I just saw this message and I thought I'd chime in. I also wrote a HOWTO to
    get dosdoors running in linux for Mystic. I don't run a BBS anymore, but I'd like to make sure the info is still available for everybody.

    I've uploaded the this same text to iNK tWO, but I'll post it here and people can just his 'X' to save it to their own local systems.

    ===================================================================
    Run DOS BBS DoorGames on the Raspberry Pi:
    by Darryl Perry 2016

    This tutorial is intended for BBS sysops who wish to run DOS door games
    on their Raspberry Pi (or other ARM device)

    This tutorial is developed with Mystic BBS as the default BBS to use. If
    you wish to use another BBS package, you will need to fix up the parts
    that are specific to the package you wish to use.

    How does this work?
    We will be creating an emulated virtual DOS environment from which to run
    our DOS door games. To do that, we will be creating a serial port into our
    VM and attching it to a computer port so that we can communicate via socat.

    Since we can mount host file systems into the DOS VM, we will not need to
    populate the VM file system with doorgame programs. This means we only need
    the bare minimum to boot and run the dos environment.

    Each time a door is ran, the script will build a batch file (run.bat) in
    the main bbs directory. When the VM boots, it will run that run.bat
    batch file to run the doorgame.

    These methods have worked for me on the following devices:
    1) Raspberry Pi B+ (raspberrypi.org)
    2) ODROID XU3-Lite (hardkernel.com)

    Caveats:
    The Raspberry Pi B+ is the least robust device I've attemted this with
    and I've had some good success with it. However, the device is inherently
    slow, so do not expect high-speed game-play like you do with traditional
    telnet doorgame activity. I would say that the speed of the display would
    be equivalent to a 1200 Baud modem.

    The ODROID XU3 is a much more robust device and the speed delay seems
    almost unnoticable.


    Required packages:
    qemu: apt-get install qemu
    socat: apt-get install socat
    todos: apt-get install tofrodos


    Create freedos image:
    We will be creating a FreeDOS image to be used in our VM.

    I find it helpful to follow this howto when creating a FreeDOS image.

    https://en.wikibooks.org/wiki/QEMU/FreeDOS

    or

    http://how-to.wikia.com/wiki/How_to_install_FreeDOS_in_QEMU

    I made my image to be 100MB. I think that it may be quite a bit
    larger than I need so you may be able to use something much smaller.

    Configure 4DOS:
    Once you have a working FreeDOS VM, you will need to configure the boot
    files for your needs:

    I find it easier to mount the image onto the local file system, and edit the
    files with VI. To mount the image:

    1) Create a mount point:
    mkdir /mnt/freedos

    2) mount the image
    sudo mount -t msdos -o loop,offset=32256 ./freedos.img /mnt/freedos

    You can then cd to /mnt/freedos/ and edit your files. You can also use
    this method for copying files to the DOS filesystem. Don't forget to
    unmount the image before running the VM.

    sudo umount /mnt/freedos

    The default boot scripts are C:\FDCONFIG.SYS and C:\FDOS\FDAUTO.BAT.
    The following has worked for me. You will want to play with your own
    configuration to meet your own needs.

    C:\FDCONFIG.SYS
    ---------------------------------------
    COUNTRY=001,858,C:\FDOS\BIN\COUNTRY.SYS
    SET DOSDIR=C:\FDOS
    LASTDRIVE=Z
    BUFFERS=20
    FILES=40
    DOS=HIGH
    DOS=UMB
    DOSDATA=UMB
    DEVICE=C:\FDOS\BIN\HIMEMX.EXE
    DEVICE=C:\FDOS\BIN\JEMM386.EXE X=TEST I=TEST I=B000-B7FF NOVME NOINVLPG SHELLHIGH=C:\FDOS\BIN\COMMAND.COM C:\FDOS\BIN /E:1024 /P=C:\FDOS\FDAUTO.BAT ---------------------------------------


    C:\FDOS\FDAUTO.BAT
    -------------------------------------
    @echo off
    SET LANG=EN
    SET MTCPCFG=C:\FDOS\MTCP.CFG
    REM SET WATTCP.CFG=C:\FDOS
    SET PATH=%dosdir%\BIN
    SET NLSPATH=%dosdir%\NLS
    SET HELPPATH=%dosdir%\HELP
    SET TEMP=%dosdir%\TEMP
    SET TMP=%TEMP%
    SET DIRCMD=/P /OGN /4
    SET COPYCMD=/-Y
    LH SHARE
    DOSLFN
    MEM /C /N
    SET AUTOFILE=%0
    SET CFGFILE=C:\FDCONFIG.SYS
    alias reboot=fdapm warmboot
    alias reset=fdisk /reboot
    alias halt=fdapm pureoff
    alias shutdown=fdapm poweroff
    alias cfg=edit %cfgfile%
    alias auto=edit %0
    REM If you install BNU in C:\BNU, take out these REMs
    REM CD \BNU
    REM BNU
    CALL E:\RUN.BAT
    ----------------------------------------

    Note how the batch file ends with CALL D:\RUN.BAT. RUN.BAT is the
    dynamically created batch file that gets created each time we run the
    doors.sh script.

    Setting up the doorgames:
    You will want to run the DOS VM initially, to setup your doorgames. To do
    that, you just run qemu normally, but with the mounted local file system.
    I've written a simple batch file that will load the VM. ----------------------------------------
    #!/bin/bash

    disp=${1:-curses}

    localdir=/home/bbs/dosdoors

    opts="-localtime "
    opts="$opts -m 2M "
    opts="$opts -display $disp "
    opts="$opts -drive file=/home/bbs/doors/qemu/freedos.img,format=raw,index=0 " opts="$opts -drive file=fat:rw:${localdir},format=raw,index=1 "
    opts="$opts -drive file=fat:rw:/home/bbs/temp1,format=raw,index=2 "
    opts="$opts -drive file=fat:rw:/home/bbs/text,format=raw,index=3 "

    qemu-system-i386 ${opts}
    ----------------------------------------

    If you are running this remotely, from a terminal like putty, you can add the
    -curses flag. That will give you an interactive shell into the VM.


    The method used for running the VM will mount the /home/bbs directory as
    the DOS D: drive. This puts all the BBS subdirectories off of D:.

    I have my doorgame files in /home/bbs/dosdoors/<game> on the host filesystem.

    My LORD directory is at /home/bbs/dosdoors/lord. When viewed from the DOS VM

    it will be located at D:\LORD

    The dropfile locations will also be on your E: drive, no matter what node you are using..
    E:\door.sys



    The working DOORS.SH script:
    This is the script as I have it working for me: ------------------------------------
    #!/bin/sh

    ## Pass the parameters for the door and the node.
    DOOR=${1}
    NODE=${2}

    DOOR=`echo ${DOOR} | tr '[a-z]' '[A-Z]'`

    ## The linux path for the run.bat file
    gobat=/home/bbs/run.bat
    ## The VM will be accessable via a computer port. I have randomly selected
    ## 20200 as a base port number to use. Each node will 'add' to the base
    ## number. IE, Node #1 will be added to 20200 and the result will be
    ## port 20201 (20200 + 1)
    ## You may change the base port to any number you wish.
    portnum=`expr 20200 + ${NODE}`

    case ${DOOR} in
    ## Operation OverKill II
    OOII)
    echo "@echo off" > ${gobat}
    echo "D:" >> ${gobat}
    echo "CD \\OO" >> ${gobat}
    ### Use the CALL command when calling a door batch file.
    ### If not used, then the door batch file will not return
    ### to the RUN.BAT script to complete execution. If the
    ### RUN.BAT script does not complete execution, then it will
    ### not shut down the VM. It will then just go to a dos
    ### prompt and the user will not see it, and will think that
    ### the game is hung.
    echo "CALL OOIIDOOR.BAT ${NODE}" >> ${gobat}
    ;;
    ## Legend of the Red Dragon
    LORD)
    echo "@echo off" > ${gobat}
    echo "D:" >> ${gobat}
    echo "CD \\LORD" >> ${gobat}
    echo "CALL START.BAT ${NODE}" >> ${gobat}
    ;;
    ## Planets: The Exploration of Space
    PLAN)
    echo "@echo off" > ${gobat}
    echo "D:" >> ${gobat}
    echo "CD \\PLAN" >> ${gobat}
    echo "PLANETS.EXE /pE:\\DOOR.SYS" >> ${gobat}
    ;;
    ## Barren Realms Elete
    BRE)
    echo "@echo off" > ${gobat}
    echo "D:" >> ${gobat}
    echo "CD \\BRE" >> ${gobat}
    echo "SRDOOR" >> ${gobat}
    echo "BRE" >> ${gobat}
    ;;
    # Space Dynasty
    DYNASTY)
    echo "@echo off" > ${gobat}
    echo "D:" >> ${gobat}
    echo "CD \\DYNASTY" >> ${gobat}
    echo "DYNASTY E:\\DOOR.SYS" >> ${gobat}
    echo "COPY \\DYNASTY\\DYNASTY.SCO F:\\" >> ${gobat}
    ;;
    # NetRunner
    NETRUN)
    echo "@echo off" > ${gobat}
    echo "C:" >> ${gobat}
    echo "C:\DOORS\bnu\bnu" >> ${gobat}
    echo "D:" >> ${gobat}
    echo "CD \\NETRUN" >> ${gobat}
    echo "NETRUN E:\\DOOR.SYS" >> ${gobat}
    ;;
    DOS)
    ;;
    esac
    ## At the end of run.bat, we add this line to gracefully shutdown the VM.
    ## This will return the user back to the BBS.
    echo "C:\FDOS\BIN\FDAPM PUREOFF" >> ${gobat}
    ## The batch file must be in dos format, or it will not run properly.
    todos ${gobat}


    ### The main QEMU call.
    ### The qemu call is loaded into the background. We do this so that we can ### spawn a concurrent socat process.
    qemu-system-i386 \
    -localtime \
    -boot c \
    -m 256 \
    -display none \
    -serial telnet::${portnum},server,nowait,nodelay \
    -drive file=/home/bbs/doors/qemu/freedos.img,format=raw,index=0 \
    -drive file=fat:rw:/home/bbs/dosdoors,format=raw,index=1 \
    -drive file=fat:/home/bbs/temp${NODE},format=raw,index=2 \
    -drive file=fat:rw:/home/bbs/text,format=raw,index=3 > /dev/null 2>&1 &

    ### -drive, index=0 is the first drive, loading the freedos image (C:\)
    ### -drive, index=1 is the door path, (D:\)
    ### -drive, index=2 is the dropfile path, (E:\)
    ### -drive, index=3 is the text dir path, (F:\) (Used for writing score.ans fil s)


    ### Inform the user that it will take several seconds before the game
    ### loads up.
    clear
    echo
    echo "Loading door... please be patient...."
    echo
    sleep 3
    ### socat is used to communicate with the VM's serial modem.
    socat -,raw,echo=0 TCP:localhost:${portnum}

    if [ -f ${gobat} ]; then
    rm -rf ${gobat}
    fi

    exit 0
    ------------------------------------

    Using the script:
    I use and have developed this method for Mystic BBS. You will need to make
    appropriate adjustments if you use a different BBS package.

    The script is called from a menu option. At the time of this writing,
    Mystic BBS is currently at 1.12a39.

    For now, you will need to call the proper doorgame menu option for the
    doorgame it is intending to launch. I try to use the DOOR.SYS dropfile
    whereever possible. That Mystic Menu Option is DD.

    The parameters for the script are:

    doors.sh DOOR NODE# /DOS

    The /DOS switch is used to create a DOS version of the drop file. That way
    there is no need to run todos on the dropfile before calling the door.

    Use %3 of course, as the MCI macro to pass the users' node number.

    Menu: DD
    Data: /home/bbs/doors/qemu/doors.sh LORD %3 /DOS

    Conclusion:
    That's all there is to it. Your milage may vary.
    Darryl Perry
    Gryphon @ Cyberia BBS

    --- Mystic BBS v1.12 A46 2020/03/29 (Windows/32)
    * Origin: .{* iNK!2 // bbs.inktwo.com \\ +o Smooth *}. (21:2/110)
  • From Alpha@21:4/158 to Gryphon on Mon Oct 19 16:40:40 2020
    111
    I just saw this message and I thought I'd chime in. I also wrote a HOWTO to get dosdoors running in linux for Mystic. I don't run a BBS anymore, but I'd like to make sure the info is still available for everybody.

    Fantastic. Are there any watch-outs or limitaions with using QEMU on a rPi? Other than performance/speed. I remember from the Enigma QEMU docs: "Note however that there is an important and major caveat: Multiple instances of a particular door/OS image should not be run at once!"

    FYI, I just received my replacement pi, I'll give your instructions a go!

    |07Ú[|08..|15Alpha|08.....................|07]¿
    |07Ã[|08..|11The Drunken Gamer BBS|08.....|07]´ |07À[|08..|03TheDrunkenGamer.com:8888|08..|07]Ù

    --- Mystic BBS v1.12 A47 2020/09/12 (Linux/64)
    * Origin: The Drunken Gamer BBS (21:4/158)
  • From Gryphon@21:2/110 to Alpha on Mon Oct 19 19:21:16 2020
    133
    On 19 Oct 2020, Alpha inked down this thought...

    I just saw this message and I thought I'd chime in. I also wrote a HO to get dosdoors running in linux for Mystic. I don't run a BBS anymor but I'd like to make sure the info is still available for everybody.

    Fantastic. Are there any watch-outs or limitaions with using QEMU on a rPi? Other than performance/speed. I remember from the Enigma QEMU docs: "Note however that there is an important and major caveat: Multiple instances of a particular door/OS image should not be run at once!"

    Yes, this is true. When you run an instance of QEMU, it is running in its own virtual machine. If you run multiple instances, you'll be running multiple isolated VM's. What this means is that any changes made in one instance will not be seen in any concurrent running VMs. So its best to allow only one node to run games at any one time.

    Since so few callers call any one BBS at the same time, I considered this to
    be only a slight issue since it will not be likely that multiple users would
    be running games at the same time.

    --- Mystic BBS v1.12 A46 2020/03/29 (Windows/32)
    * Origin: .{* iNK!2 // bbs.inktwo.com \\ +o Smooth *}. (21:2/110)
  • From Avon@21:1/101 to Gryphon on Tue Oct 20 15:37:58 2020
    On 16 Oct 2020 at 06:55a, Gryphon pondered and said...

    I just saw this message and I thought I'd chime in. I also wrote a HOWTO to get dosdoors running in linux for Mystic. I don't run a BBS anymore, but I'd like to make sure the info is still available for everybody.

    Hey good sir :)

    Nice to see you active in the echos, hope life's treating you well.

    I *think* I may have asked this before (old age memory) but would you be OK
    if I added this content to the fsxNet wiki with attribution to yourself?

    Best, Paul

    --- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Gryphon@21:2/110 to Avon on Tue Oct 27 08:29:58 2020
    133
    On 20 Oct 2020, Avon inked down this thought...

    On 16 Oct 2020 at 06:55a, Gryphon pondered and said...

    I just saw this message and I thought I'd chime in. I also wrote a HO to get dosdoors running in linux for Mystic. I don't run a BBS anymor but I'd like to make sure the info is still available for everybody.

    Hey good sir :)

    Nice to see you active in the echos, hope life's treating you well.

    I *think* I may have asked this before (old age memory) but would you be OK if I added this content to the fsxNet wiki with attribution to yourself?

    Best, Paul

    Sure. Just show me where and how.

    --- Mystic BBS v1.12 A46 2020/03/29 (Windows/32)
    * Origin: .{* iNK!2 // bbs.inktwo.com \\ +o Smooth *}. (21:2/110)
  • From Nazferiti@21:3/107 to All on Tue May 5 00:34:54 2020
    Been running a Win32 version of Mystic for about 45 days now and have got a
    lot of things sorted out, but there are limits to what I can do running on a 32-bit version of Windows 2008 Server.

    I've been experimenting with Linux and I have a fully functional version of Mystic 64-Bit running on an Ubuntu 20.04 version of linux in a VM. I am however stuck on getting doors running and if I am going to move things to Linux I need to find a solution.

    When I launch doors I get the following error, I have fooled around with permissions but have not come up with a solution as of yet.

    mkdir: cannot create directory /root permission denied
    can't create local /root/.dosemu directory
    can't create local /root/.dosemu/run directory
    can't open "/root/.dosemu/boot.log" for writing

    I am aware of door servers and whatnot that I could either push traffic to or create my own Windows door server. I have one installed, and have played
    with it - but that's really not the way I want to do this.

    Has anybody encountered this before?

    - Mike

    --- Mystic BBS v1.12 A45 2020/02/18 (Windows/32)
    * Origin: Arcadia BBS | Putnam, CT | telnet.arcadiabbs.com (21:3/107)
  • From ryan@21:1/168 to Nazferiti on Mon May 4 21:38:48 2020
    When I launch doors I get the following error, I have fooled around with permissions but have not come up with a solution as of yet.

    The errors you listed are unfortunately a case of launching mis as the root user. Even though it drops privileges to the owner, it still messes up things like launching doors.

    Try launching mis as the regular user and see if you get further. You may
    have to find a workaround to bind to low ports as a regular user, though
    (check out the 'setcap' command and read up on this in the mystic wiki).

    --- Mystic BBS v1.12 A46 2020/04/13 (Linux/64)
    * Origin: monterey bbs (21:1/168)
  • From Alpha@21:4/158 to Nazferiti on Tue May 5 07:13:08 2020
    111
    When I launch doors I get the following error, I have fooled around with permissions but have not come up with a solution as of yet.

    mkdir: cannot create directory /root permission denied
    can't create local /root/.dosemu directory
    can't create local /root/.dosemu/run directory
    can't open "/root/.dosemu/boot.log" for writing

    Just to echo what ryan said, it is indeed that you probably started ./mis as root. If you run as a non-root user, make sure you CHOWN all the files/dirs
    to that user (e.g. sudo chown -R bbsuser:bbsuser /mystic (or wherever it is located).

    When running as non-root, dosemu will look in that bbsuser's home folder by default for relevant config/autoexec.bat files (e.g. something like /home/user/bbsuser/.dosemu/drive_c/autoexec.bat)


    |14Þ |07Alpha
    |14ÜÝ |13Card & Claw BBS
    |06Þ |05cardandclaw.com:8888

    --- Mystic BBS v1.12 A46 2020/04/26 (Linux/64)
    * Origin: Card & Claw BBS (21:4/158)
  • From Nazferiti@21:3/107 to Alpha on Tue May 5 13:16:34 2020
    Just to echo what ryan said, it is indeed that you probably started
    ./mis as root. If you run as a non-root user, make sure you CHOWN all
    the files/dirs to that user (e.g. sudo chown -R bbsuser:bbsuser /mystic (or wherever it is located).

    This was actually the first thing I tried, all the directorys are set as
    chown to my user account on the machine. Everything launched but the telnet and binkp ports were unable to initialize on the mis server when launch as a regular user account.

    When running as non-root, dosemu will look in that bbsuser's home folder by default for relevant config/autoexec.bat files (e.g. something like /home/user/bbsuser/.dosemu/drive_c/autoexec.bat)

    I had modified the autoexec located in /etc/dosemu

    Should I be modifying it in the user directory instead?

    - Mike

    --- Mystic BBS v1.12 A45 2020/02/18 (Windows/32)
    * Origin: Arcadia BBS | Putnam, CT | telnet.arcadiabbs.com (21:3/107)
  • From ryan@21:1/168 to Nazferiti on Tue May 5 10:26:40 2020
    This was actually the first thing I tried, all the directorys are set as chown to my user account on the machine. Everything launched but the telnet and binkp ports were unable to initialize on the mis server when launch as a regular user account.

    Check out the 'setcap' command like I mentioned.

    Pro-tip - you /won't/ have a happy setup with dosemu (potentially python and other stuff) if you launch mis as root.

    Check out the mystic wiki for other ways around this, like I mentioned previously.

    I had modified the autoexec located in /etc/dosemu

    Should I be modifying it in the user directory instead?

    This won't help. You need to launch mis as non-root and then it will use your user home directory for the dosemu config.

    Trust me when I say this is the only reasonable way to run dosemu in mystic :)

    --- Mystic BBS v1.12 A46 2020/04/13 (Linux/64)
    * Origin: monterey bbs (21:1/168)
  • From Alpha@21:4/158 to Nazferiti on Tue May 5 10:50:50 2020
    111
    This was actually the first thing I tried, all the directorys are set as chown to my user account on the machine. Everything launched but the telnet and binkp ports were unable to initialize on the mis server when launch as a regular user account.

    Yeah, that's the privileged port thing. You can use something like 'setcap'
    or you can take the easy way out and change the ports in Mystic to something non-privileged (e.g. above 1023 -- like 9000 for telnet, for example). Additionally, that'd probably cut down on hack attempts as well vs. using the standard port 23.

    I had modified the autoexec located in /etc/dosemu
    Should I be modifying it in the user directory instead?

    According to the docs, starting with version 1.0.2, DOSEMU configuration
    files are no longer in /etc but in the user's HOME directory in ~/dosemu.

    Hope that helps!


    |14Þ |07Alpha
    |14ÜÝ |13Card & Claw BBS
    |06Þ |05cardandclaw.com:8888

    --- Mystic BBS v1.12 A46 2020/04/26 (Linux/64)
    * Origin: Card & Claw BBS (21:4/158)
  • From Alpha@21:4/158 to Alpha on Tue May 5 10:56:30 2020
    111
    According to the docs, starting with version 1.0.2, DOSEMU configuration files are no longer in /etc but in the user's HOME directory in ~/dosemu.

    Forgot to mention, the first time you run Dosemu it creates the folder/file
    in that user's home directory...


    |14Þ |07Alpha
    |14ÜÝ |13Card & Claw BBS
    |06Þ |05cardandclaw.com:8888

    --- Mystic BBS v1.12 A46 2020/04/26 (Linux/64)
    * Origin: Card & Claw BBS (21:4/158)
  • From maskreet@21:1/114 to ryan on Tue May 5 13:59:16 2020
    On 05 May 2020, ryan said the following...

    This was actually the first thing I tried, all the directorys are se chown to my user account on the machine. Everything launched but the telnet and binkp ports were unable to initialize on the mis server wh launch as a regular user account.

    Check out the 'setcap' command like I mentioned.

    Pro-tip - you /won't/ have a happy setup with dosemu (potentially python and other stuff) if you launch mis as root.

    Yeah, I've been pushing the setcap command for people since I moved to Linux.

    Something people reading this considering using setcap to run ports on the currently logged in user and privileged ports: once you upgrade your mis executable (or any other with setcap) you'll have to set it again on the new executable.

    I get around this by invoking MIS and a bunch of other stuff on startup with
    a bash script, so I also plopped the setcap command in there as well just so
    I don't have to remember to do it again after upgrading.

    And since you might have to use sudo to run it, and it won't run without prompting normally, you can get around it with this (not really secure since you store your system pw in a text file):

    echo "your system pw here" | sudo -S setcap 'cap_net_bind_service=+ep' /mystic/mis

    --- Mystic BBS v1.12 A46 2020/04/29 (Linux/64)
    * Origin: throwbackbbs.com -\- meriden, ct -\- (21:1/114)
  • From ryan@21:1/168 to maskreet on Tue May 5 12:16:08 2020
    Something people reading this considering using setcap to run ports on
    the currently logged in user and privileged ports: once you upgrade your mis executable (or any other with setcap) you'll have to set it again on the new executable.

    Hmmm, you got me thinking. I run mis via a systemd script. I think there's a way systemd can monitor for changes to a file (like an upgrade) and it'll trigger a task once it detects something, so maybe there can be an automatic way to invoke the setcap command to run as root once it notices mis has been updated.

    I'm gonna store this one in my thinking cap and see if I can come back to it later today :)

    --- Mystic BBS v1.12 A46 2020/04/13 (Linux/64)
    * Origin: monterey bbs (21:1/168)
  • From Nazferiti@21:3/107 to Alpha on Tue May 5 20:34:32 2020
    Yeah, that's the privileged port thing. You can use something like 'setcap' or you can take the easy way out and change the ports in Mystic to something non-privileged (e.g. above 1023 -- like 9000 for telnet,
    for example). Additionally, that'd probably cut down on hack attempts as well vs. using the standard port 23.

    This actually pointed me in the right direction, though I am not going to
    mess with setcap because it looks like I would need to make the changes every thime i upgrade. I just set the port to 2023 and will set my ip forwarding ruls on the router to redirect 23=>2023.

    These changes fixed the initial errors I was having and all the errors are gone, the problem is the BBS just hangs now when you enter a door. The best
    I can figure is that it is launching in local mode. For the purposes of this test I actually was testing on the Tradewars 2002 editor which can run as a door. I've included relevant info below, hopefully somebody sees a mistake somewhere. This works when I log in locally to the bbs, and loads tedit
    which leads me to believe that I have either made a mistake with the com port or the fossil.

    [MENU OPTION]
    (DD) Exec external program
    stty cols 80 rows 25 && dosemu -I"serial { com 1 virtual }" "/bbs/doors/TW2002/TEDIT.BAT" %3 /DOS

    [TEDIT.BAT] (Batch File)
    @ECHO OFF
    SET RTM=EXTMAX 1024
    CD D:\DOORS\TW2002\
    D:\DOORS\TW2002\TEDIT.EXE TWNODE=%1 NOXMS NOEMS BUFFER=16500 MULTITASK=YES

    [AUTOEXEC.BAT]
    @echo off
    prompt $p$g
    path=z:\bin;z:\dosemu
    lredir d: linux\fs\bbs\
    d:
    cd \doors
    bnu
    unix -e

    --- Mystic BBS v1.12 A45 2020/02/18 (Windows/32)
    * Origin: Arcadia BBS | Putnam, CT | telnet.arcadiabbs.com (21:3/107)
  • From Vk3jed@21:1/109 to maskreet on Wed May 6 18:55:00 2020
    On 05-05-20 13:59, maskreet wrote to ryan <=-

    Yeah, I've been pushing the setcap command for people since I moved to Linux.

    I use it.

    Something people reading this considering using setcap to run ports on
    the currently logged in user and privileged ports: once you upgrade
    your mis executable (or any other with setcap) you'll have to set it
    again on the new executable.

    Yes, that's a big trap.:)

    I get around this by invoking MIS and a bunch of other stuff on startup with a bash script, so I also plopped the setcap command in there as
    well just so I don't have to remember to do it again after upgrading.

    I'd put that into my upgrade routine. I have a script that calls setcap with the correct options, just to save my memory and fingers. :D


    ... Violence is the last word of the incompetant. Also the first.
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)