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?
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
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.
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
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.
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.
that said, you could do it with, say, an LXC container that has all the doors in it and then just rlogin from the bbs machine to that so then there's another menu with is handled by a different "VM" and that leaves the bbs machine "free-er".
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,
...
your problem with that is you're going to have a different IP port for
each door. for some of the places like mine that only have a few
wouldnt be a problem, but for others that have (and i've seen one with
like 160) that's going to be unweildy.
that said, you could do it with, say, an LXC container that has all
the doors in it and then just rlogin from the bbs machine to that so
then there's another menu with is handled by a different "VM" and that leaves the bbs machine "free-er".
By: Charles Blackburn to Tracker1 on Thu Sep 22 2022 07:42 am
that said, you could do it with, say, an LXC container that has all the doors in it and then just rlogin from the bbsI would like to know more about this method. I am presently running the BBS under Proxmox, which supports LXC containers. I
machine to that so then there's another menu with is handled by a different "VM" and that leaves the bbs machine
"free-er".
haven't ever played around with them, so I will need to look into them.
your problem with that is you're going to have a different IP port forNot really... they wouldn't need to be public facing... a single service could act as a intermediary, then relaying to the correct instance.
each door. for some of the places like mine that only have a few
wouldnt be a problem, but for others that have (and i've seen one with
like 160) that's going to be unweildy.
that said, you could do it with, say, an LXC container that has all
the doors in it and then just rlogin from the bbs machine to that so
then there's another menu with is handled by a different "VM" and that leaves the bbs machine "free-er".
Something like that... basically each "door" would be it's own super-light host... so that it's easier to vary setups for doors,
isolate data, etc. Then the main host/system that actually takes users
to pass to the given door host.
Either too complex, or too simple, maybe. But each single-door host can have a web-admin console launcher. Either qemu or dosemu options could
be supported separately... Don't have it right in front of me, but there's a really basic network file host that works in freedos as a client, not sure on dosemu, but would allow each door to have a drive image mounted, that isolates the door's storage.
I am familiar with containers in general, as I use Docker for some things. When you create a container for door games, are
you using another copy of the BBS as a front-end? It would seem that you need something to manage the connectivity between
the doors container and the main BBS. The only down side I see to using another BBS would be that the users would need to
create another account.
If I were to consider a method like that, I would probably just try to
run the DOS door games on a Windows box instead of Linux, since dosemu2 is being so stubborn.
isnt that always the case. i prefer the keep it sinmple stuff for
the most part. as for the simple file server program, you could theoretically use nfs (there are dos nfs clients). but i would
think if it runs in freedos it should run in dosemu as they are
pretty much the same underlying system. but then of course you
could always run drdos under dosemu too lol
as for the doors having a different drive image, you would then
have to get into the process of handling file contention if
multiple processes are running at the same time using the same
files :D
I am familiar with containers in general, as I use Docker for some
things. When you create a container for door games, are you using
another copy of the BBS as a front-end?
It would seem that you need something to manage the connectivity
between the doors container and the main BBS. The only down side I
see to using another BBS would be that the users would need to
create another account.
If I were to consider a method like that, I would probably just try
to run the DOS door games on a Windows box instead of Linux, since
dosemu2 is being so stubborn.
On 9/24/22 03:17, Charles Blackburn wrote:<CUT>
isnt that always the case. i prefer the keep it sinmple stuff for
the most part. as for the simple file server program, you could theoretically use nfs (there are dos nfs clients). but i
Only preference for freedos/qemu over dosemu is mainly that you can support ARM with the former and not that latter. In terms of file
sharing was thinking EtherDFS[1] for the file sharing... but could just as easily use SMB/CIFS or NFS. Main concern is getting share support working.
It would seem that you need something to manage the connectivityYeah... usually with a door host server, you would configure it to not ask any questions... with synchronet you can disable all newuser questions, and configure rlogin and edit the logon.js to push the user logins straight into a requested door.
between the doors container and the main BBS. The only down side I
see to using another BBS would be that the users would need to
create another account.
Yeah... usually with a door host server, you would configure it to
not ask any questions... with synchronet you can disable all newuser
questions, and configure rlogin and edit the logon.js to push the
user logins straight into a requested door.
that's interesting... are there any destructions on setting that up? I
not ask any questions... with synchronet you can disable all newuser
questions, and configure rlogin and edit the logon.js to push the
user logins straight into a requested door.
that's interesting... are there any destructions on setting that up? IDestructions? ;)
Yeah... usually with a door host server, you would configure it
to not ask any questions... with synchronet you can disable all
newuser questions, and configure rlogin and edit the logon.js to
push the user logins straight into a requested door.
that's interesting... are there any destructions on setting that
up? I would love to do something like that.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 411 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 107:00:20 |
| Calls: | 8,595 |
| Calls today: | 8 |
| Files: | 13,229 |
| Messages: | 5,934,996 |