On 9/6/22 18:50, Gamgee wrote:I agree. i did upgrade from debian 10 to 11 and los dosemu1 , now i have compiled dosemu2 and work with some tweks at sbbs files.
I don't know the answers to what you ask.
I can tell you, however, that I've seen this same question asked here
several times, and it's been discussed at length on the SBBS IRC channel
as well. As far as I know, it has never been successfully deployed
other than maybe for some certain specific doors. The short answer is
that it doesn't/won't work properly.
Recommend you just use the original DOSEMU.
The issue at hand is a lot of distributions no longer contain the
original DOSEMU in repositories, only DOSEMU2 ... so holding on to the
older version introduces more friction than less.
Given that, it may be worthwhile to add the older DOSEMU to the 3rdp codebase and build in linux environments directly if the current version supported by most Linux distributions isn't what is being used/supported.
The dosemu.conf file is passed as a parameter at the bottom of the dosemu.ini file.
Here's what I am using at the moment. Still tweaking things trying to get them
working.
Change the /home/bbs to match the current user that you run the board under in
Linux. This will determine which drive C: gets used.
I agree. i did upgrade from debian 10 to 11 and los dosemu1 , now i have compiled
dosemu2 and work with some tweks at sbbs files.
Given that, it may be worthwhile to add the older DOSEMU to the 3rdp
codebase and build in linux environments directly if the current
version supported by most Linux distributions isn't what is being
used/supported.
I agree. i did upgrade from debian 10 to 11 and los dosemu1 , now i
have compiled dosemu2 and work with some tweks at sbbs files.
Havent gogtten around to figuring out how to start it from the command line yet so that I can verify that the drive letters are good...I copy the startup command from the dosemu.ini file into a shell script and then execute that script. Modify it in the script to taste, then copy it back to the .ini file when done.
Any thoughts?
run doors that way... which seems like a lot of effort. Have considered writing an
explicit door server app/suite that just accepts connections
with a TOTP code for the user from the bbs (RLOGIN) and runs the door(s) directly
that way (QEMU/FreeDOS).
I copy the startup command from the dosemu.ini file into a shell script and then
execute that script. Modify it in the script to taste, then copy it back to the .ini
file when done.
run doors that way... which seems like a lot of effort. Have
considered writing an explicit door server app/suite that just
accepts connections with a TOTP code for the user from the bbs
(RLOGIN) and runs the door(s) directly that way (QEMU/FreeDOS).
I wonder if it wouldnt just be a heck of a lot easier to build
an RLOGIN server for freedos and just be done with it. Might be
able to do something like comm0comm for the comm port to tcp
socket conversion maybe?
Kind of my thinking as well... the issue becomes supporting doors with multiple users, so kind of need to accept at least
the initial connection outside FreeDOS, but at that point, could pass to a DOS based
BBS as the door host altogether.
Also thoughts on reducing overhead and load balancing at scale, which is a more distant concern to say the least just where my mind goes because of the work I do.yea i think in this "niche" market there's no-one running more than a couple of people at a time nowadays. not like the "good ol' days" where my 8 line system i used to help maintain was constantly at least half full all day every day.
Ragnarok wrote to Tracker1 <=-
> >> Given that, it may be worthwhile to add the older DOSEMU to the 3rdp
> >> codebase and build in linux environments directly if the current
> >> version supported by most Linux distributions isn't what is being
> >> used/supported.
> >
> > I agree. i did upgrade from debian 10 to 11 and los dosemu1 , now i
> > have compiled dosemu2 and work with some tweks at sbbs files.
>
> Haven't really messed with either one... It seems like dosemu2 has been
> around for about 7 years now.
Ra> yeah dosemu2 have many years.. I just use dosemu1 because my
Ra> server was on debian jessie.. and sbbs work out of the box
Ra> (minimal tweaks) with dosbox1.
Ra> Now i upgrade to debian 11 that do not have dosemu1. So I had
Ra> force to move to dosemu2
Well.... not really. You're not *forced* to use dosemu2. Just because
a software package isn't in a debian repository doesn't mean it can't be installed. It's no harder than downloading the dosemu1 .deb package and installing it manually.
Morpheus wrote to All <=-
Hello all, I am attempting to add some old DOS door games using
dosemu2 under Ubuntu Server 20.04.4, and the BBS keeps trying to
execute D:external.bat. DOSEmu2 has different default drive
mappings than DOSEmu1, so external.bat is actually on G:, not D:.
Where can I change the behavior of the default vars like $EXTBAT
to point to the correct drives?
I am attempting to execute LORD v4.06 which is installed on the
default C drive for the user that the BBS is running under. I
was able to map the HOME directory to get this drive to show up
as C: So my drives are as follows; C: -
/home/{bbsuser}/.dosemu/drive_c D: - DOSEMU default
E: - COMSPEC default
F: - BAT default
G: - NODEx
If anyone could point me in the right direction, it would be
greatly appreciated!
Hello all, I am attempting to add some old DOS door games using dosemu2 under Ubuntu Server 20.04.4, and the BBS keeps trying to execute D:external.bat. DOSEmu2 has different default drive mappings than DOSEmu1, so external.bat is actually on G:, not D:. Where can I change the behavior of the default vars like $EXTBAT to point to the correct drives?
I am attempting to execute LORD v4.06 which is installed on the default C drive for the user that the BBS is running under. I was able to map the HOME directory to get this drive to show up as C: So my drives are as follows;
C: - /home/{bbsuser}/.dosemu/drive_c
D: - DOSEMU default
E: - COMSPEC default
F: - BAT default
G: - NODEx
If anyone could point me in the right direction, it would be greatly appreciated!
-Morpheus
---
� Synchronet � TW Lounge BBS - bbs.twlounge.net
El 6/9/22 a las 12:59, Morpheus escribió:
Hello all, I am attempting to add some old DOS door games using
dosemu2 under Ubuntu Server 20.04.4, and the BBS keeps trying to
execute D:external.bat. DOSEmu2 has different default drive mappings
than DOSEmu1, so external.bat is actually on G:, not D:. Where can I
change the behavior of the default vars like $EXTBAT to point to the
correct drives?
I am attempting to execute LORD v4.06 which is installed on the
default C drive for the user that the BBS is running under. I was
able to map the HOME directory to get this drive to show up as C:Â So
my drives are as follows;
C: - /home/{bbsuser}/.dosemu/drive_c
D: - DOSEMU default
E: - COMSPEC default
F: - BAT default
G: - NODEx
If anyone could point me in the right direction, it would be greatly
appreciated!
-Morpheus
---
 � Synchronet � TW Lounge BBS - bbs.twlounge.net
you can solve if add the mappings via cmdline as i commented at:
https://gitlab.synchro.net/main/sbbs/-/issues/433#note_2713
you must edit ctrl/dosemu.conf and exec/dosemu.ini
you can solve if add the mappings via cmdline as i commented at: https://gitlab.synchro.net/main/sbbs/-/issues/433#note_2713
you must edit ctrl/dosemu.conf and exec/dosemu.ini
this settings did the trick:
$_hdimage = "+0 -2 /sbbs/ctrl /sbbs/data /sbbs/exec +1"
Hello all, I am attempting to add some old DOS door games using dosemu2 under Ubuntu Server 20.04.4, and the BBS keeps trying to execute D:external.bat. DOSEmu2 has different default
drive mappings than DOSEmu1, so external.bat is actually on G:, not D:. Where can I change the behavior of the default vars like $EXTBAT to point to the correct drives?
Re: Re: DOSEmu2
By: Ragnarok to Tracker1 on Thu Sep 08 2022 23:11:19
Ra> I agree. i did upgrade from debian 10 to 11 and los dosemu1 , now i have compiled
Ra> dosemu2 and work with some tweks at sbbs files.
any chance you can write up a doc on what files you changed to what. heck maybe even sanitize your files and send them through as a zip so we can at least have a "start".}
Also, how do you get the door files into dosemu (yes i know it's just a directory, but which one :D)
Is it possible to start dosemu from the terminal to test it to make sure we got it all correct first ?
Charles Blackburn
SYSOP - The F.B.O BBS
Aviation related fun @ bbs.thefbo.us IPV4 and IPV6
DOVE-Net
Coming soon: FSX-Net, FIDO-Net
---
� Synchronet � My Brand-New BBS
On 9/8/22 19:11, Ragnarok wrote:yeah dosemu2 have many years.. I just use dosemu1 because my server was
Given that, it may be worthwhile to add the older DOSEMU to the 3rdp
codebase and build in linux environments directly if the current
version supported by most Linux distributions isn't what is being
used/supported.
I agree. i did upgrade from debian 10 to 11 and los dosemu1 , now i
have compiled dosemu2 and work with some tweks at sbbs files.
Haven't really messed with either one... It seems like dosemu2 has been around for about 7 years now.
Ragnarok wrote to Tracker1 <=-
Given that, it may be worthwhile to add the older DOSEMU to the 3rdp
codebase and build in linux environments directly if the current
version supported by most Linux distributions isn't what is being
used/supported.
I agree. i did upgrade from debian 10 to 11 and los dosemu1 , now i
have compiled dosemu2 and work with some tweks at sbbs files.
Haven't really messed with either one... It seems like dosemu2 has been around for about 7 years now.
yeah dosemu2 have many years.. I just use dosemu1 because my
server was on debian jessie.. and sbbs work out of the box
(minimal tweaks) with dosbox1.
Now i upgrade to debian 11 that do not have dosemu1. So I had
force to move to dosemu2
any chance you can write up a doc on what files you changed to what. heck maybe even sanitize your files and send themyes.. plase wait me some time i'm busy at work, but I will update the dosemu wiki page asap
through as a zip so we can at least have a "start".}
REM For debugging: /usr/bin/env HOME=/sbbs/ctrl/ QUIET=1 DOSDRIVE_D=/sbbs/nodes/node1/ NODEDIR=/sbbs/nodes/node1/
/usr/bin/dosemu.bin -d /sbbs/nodes/node1/ -d /sbbs/doors/dos -I"video { none }" -I'keystroke "\n"' -f/sbbs/ctrl/dosemu.co
nf -ED:external.bat -o/sbbs/nodes/node1/dosemu_boot.log
I don't know the answers to what you ask.
I can tell you, however, that I've seen this same question asked here
several times, and it's been discussed at length on the SBBS IRC channel
as well. As far as I know, it has never been successfully deployed
other than maybe for some certain specific doors. The short answer is
that it doesn't/won't work properly.
Recommend you just use the original DOSEMU.
Tracker1 wrote to Gamgee <=-
I don't know the answers to what you ask.
I can tell you, however, that I've seen this same question asked here several times, and it's been discussed at length on the SBBS IRC channel
as well. As far as I know, it has never been successfully deployed
other than maybe for some certain specific doors. The short answer is
that it doesn't/won't work properly.
Recommend you just use the original DOSEMU.
The issue at hand is a lot of distributions no longer contain the
original DOSEMU in repositories, only DOSEMU2 ... so holding on
to the older version introduces more friction than less.
Given that, it may be worthwhile to add the older DOSEMU to the
3rdp codebase and build in linux environments directly if the
current version supported by most Linux distributions isn't what
is being used/supported.
Lucky, I've been struggling with that to get it to recognise the dosemu.conf in the sbbs directory. To even get as far as you.
Any pointers appreciated
Also thoughts on reducing overhead and load balancing at scale, which
is a more distant concern to say the least just where my mind goes
because of the work I do.
yea i think in this "niche" market there's no-one running more than
a couple of people at a time nowadays. not like the "good ol' days"
where my 8 line system i used to help maintain was constantly at least
half full all day every day.
Of course... most of the multi-bbs door hosts are single-system even as far as I know. But it's an interesting thought exercise all the same.
I mean even each door having it's own listener, that takes an rlogin connection, and launches straight into a specific door
wouldn't be too
bad... easy enough to containerize, and just need mounted storage and ensuring a single service instance per door... kind of against the redundancy, but at least a single downed node will allow to rebalance
the door instances to other hosts.
| Sysop: | Zazz |
|---|---|
| Location: | Mesquite, Tx |
| Users: | 7 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 76:59:08 |
| Calls: | 157 |
| Files: | 2,110 |
| Messages: | 145,577 |