On 18/02/2026 23:20, Andrew Leary wrote: This will require thorough testing to ensure that it doesn't break other parts of the system. Until I have time for testing it, this change will not be committed to the git repository. Please tell me why you are considering doing this as in my older state (79 this year) I cannot think of a reason for it as it is simple to set up the system to use /home instead of /opt although I did have to modify SETUP.sh -> SETUP2.sh for it. There again I could, be wron...
This will require thorough testing to ensure that it doesn't break other parts of the system. Until I have time for testing it, this change will not be committed to the git repository. Andrew On Wed, Feb 18, 2026, 3:37 PM Adam Clark kinetix242@users.sourceforge.net wrote: The mbtask binary is designed to be started by root, normally in a system startup script. It handles the tasks that require privileges, then drops privileges to the mbse user. Unless you're running a different system than what's...
The mbtask binary is designed to be started by root, normally in a system startup script. It handles the tasks that require privileges, then drops privileges to the mbse user. Unless you're running a different system than what's published here, that's not true. mbtask, as most of the mbse binaries are installed, are run as the mbse user, SETUID root. That's a huge difference from running as the root user - in that, mbse's environment is there, intact, when the binary is run, including the MBSE_ROOT...
The mbtask binary is designed to be started by root, normally in a system startup script. It handles the tasks that require privileges, then drops privileges to the mbse user. Unless you're running a different system than what's published here, that's not true. mbtask, as most of the mbse binaries are installed, are run as the mbse user, SETUID root. That's a huge difference from running as the root user. If they were run as the root user, there'd be no user to drop privilege levels to. You have...
The mbtask binary is designed to be started by root, normally in a system startup script. It handles the tasks that require privileges, then drops privileges to the mbse user. You have given me no reason to change a design that works, simply because you want to have MBSE_ROOT assigned somewhere different that the mbse user's home directory. Such a change would also require reworking several other mbse programs, including mbuseradd and mbpasswd, which require root privileges to accomplish their particular...
I believe the item that's compelling is the complexity around having multiple places where "root" for mbse is determined, and I know of no other software that claims it pays attention to a environment variable to determine it's root, and then also uses a user's home directory as a determining factor as well. Your description of the startup process seems to be incorrect. MBSE is started as the mbse user which is why the binaries have setUID on them - it requires root privileges to bind to privileged...
Added non-compliant directory warning
As Andrew has stated the mbse root and mbse home path must be the same and when building mbse from source and using configure --prefix=/home clears any issues you should be having. mbtask takes its pre-data based on default home folder unless changed by the use of prefix during the build process.
$MBSE_ROOT should be the determining environment ROOT, not pw->pw_dir
The BBS is designed by the original author to have the MBSE_ROOT set to the same directory as the home directory for the mbse user. I haven't dug too deeply into the mbtask code yet, but I imagine 1 reason for this is that mbtask is initially started as root and then drops privileges to the mbse user. The root user doesn't have MBSE_ROOT set, so mbtask needs to use another means to find the files it needs until it switches to user mbse. Unless someone can give me a compelling reason to change this,...
Sorry forgot you must build mbse with this remembering to read the content of INSTALL but change the instruction ./configure to: ./configure --prefix=home instead of just without any params. Then continue with the instructions in INSTALL, i..e., make > build.log 2>build.err then ls -la build.* checking / looking at content of build.err for any warnings etc. then tail build.log to confirm it build the system. then follow INSTALL Note when you have to run as root and then as mbse after running SETUP2.sh...
Hi there... This is really about having a difference of MBSE_ROOT and the mbse user's home directory. I haven't seen anything in the bits I've been looking at that suggests having a different installation prefix would cause problems if MBSE_ROOT and the mbse user's home directory are set to the same place.
There has been other changes (although more should also be done) for s/w updates over the years. I have not updated the html as too much of a pain and I only use the PDF file for a reference anyway.
Last used for 1.1.7 and reinstalling on new /home partition and a upgrade as well.
I use /home/mbse as I have multi boot partitions that can be in operation so I have the following replacement script over SETUP.sh as SHELL2.sh, see attachment Basically consists of changing all occuracies of "/opt" with /home". There might be micro changes to suuport by distro - Mageia v9 - sorry cannot remember but should not interfere for you but recommend you look at the script any way.
$MBSE_ROOT should be the determining environment ROOT, not pw->pw_dir
Updated SETUP.sh
Updated README and AUTHORS
Removed outdated unofficial documentation
v1.1.7 - Add missing ChangeLog_2025
v1.1.7 - Add origin node to file announcements/enable guest accounts.
v1.1.6 - Make MBFIDO and MBMSG respect the empty tearline option.
Home
MBSE v1.1.5 - New update
v1.1.5 - Update README
v1.1.5 - Bump version number to match previous commit.
v1.1.5 - Add new text file control code (CTRL-L) to clear user's screen.
v1.1.4 - Add ability to suppress tearlines in NetMail/use an empty tearline. i
v1.1.3 - Change /U for doors to Unixname only; add /H for home directory.
mboutq 1.1.8 Update
mboutq v1.1.5 Released
The .?lo files are removed when all files listed in them have been sent. They don't remain until midnight; only the truncated ARCmail bundles do. Andrew On Thu, Jul 10, 2025, 7:47 AM Vincent (Bryan) Coen vcoen@users.sourceforge.net wrote: No, using the create date of ?lo / ?ut files themselves is wrong as new files can be added at any time up to the date/time the file is removed which I assume is during the midnight running script. I admit that using the create date of ech file CAN be wrong if sysop...
The create date/time of the .?lo file is the time that the first file was queued for the destination. Since the objective here is to know how long the oldest file has been in the queue, that date/time is as close as we can get without redesigning the entire outbound structure. Granted, it can be off some if the transfer is aborted after that first file is sent, but others remain in the queue. I will look at your program to see what differences you have in how you figure aging. Andrew On Thu, Jul...
No, using the create date of ?lo / ?ut files themselves is wrong as new files can be added at any time up to the date/time the file is removed which I assume is during the midnight running script. I admit that using the create date of ech file CAN be wrong if sysop changes the archive without using the original date but as far as I know I do retain it. I hav gone through all files for some nodes that have a lot on hold due to being not pollable and the ageing is working correctly - at least for me...
Using the date of the .?lo files to determine how long files have been queued for a node is not wrong. In fact, it is likely more accurate in cases where a node only has files queued without any packets or ARCmail bundles. The date/timestamp of files that have been hatched into file echoes is not correct to use, as too often these dates/times are changed when the files are sent between systems, converted to new archive formats, or similar manipulation that takes place on many nodes. The .?lo file...
What you did not mention was that the sizes and ages are accurate as mbout mis-uses such and in many cases uses the wrong values such as the date of the ?lo and ?ut files which is totally wrong and double counts files on hold not including the size of the TICs etc. There are other possible errors that I gave up looking for but give me a shout and I will supply my source code but be warned, it is written in Cobol. Nuts I will add the current version here along with associated documentation etc as...
I spot checked several of the nodes in your screen shots; the MBOUT numbers divided by 1024 match exactly the numbers your program shows. I do like how your program sorts the output, and the option to display errors if present. I'm considering adding those to MBOUT when I get sone time to work on it. Andrew On Wed, Jul 9, 2025, 3:50 PM Vincent (Bryan) Coen vcoen@users.sourceforge.net wrote: Oops forgot the screen grab for mboutq E Attachments: Screenshot_20250709_204754.png https://sourceforge.net/p/mbsebbs/tickets/_discuss/thread/8c8e0d37/60f7/attachment/Screenshot_20250709_204754.png...
Oops forgot the screen grab for mboutq E
Still present for 1.1.1 BUT I have now written a program to deal with all these issues with some extra features like 1. Size are human readable with k and m signifying Kilobytes and Megabytes with option of not doing so (option B) . 2. Show Connect Error codes and the text (option E). screen 1 mine as mboutq and 2 - mbout sta
v1.1.2 - Update example German language files to fix message reader issues.
Updated MBSE docs
Minor update - missing logo.
Updated MBSE docs
Update: I've been able to fix this issue by commenting out lines 43-45 in unix/mblogin.c /***** OBSOLETE !!! #if defined(__NetBSD__) #undef HAVE_UTMPX_H #endif ******/ Since I am not familiar with the long, distant history of NetBSD I suppose that this piece of code originates from at least 2018. Since compiling the code now works without this directive, chances are that something changed "under the hood" of NetBSD or the directive got there by accident.
Update: I've been able to fix this issue by commenting out lines 43-45 in unix/mblogin.c /***** OBSOLETE !!! #if defined(__NetBSD__) #undef HAVE_UTMPX_H #endif ******/ Since I am not familiar with the long, distant history of NetBSD I suppose that this piece of code originates from at least 2018. Since compiling the code now works without these directives, chances are that something changed "under the hood" of NetBSD or the directives got there by accident.
Update: I've been able to fix this issue by commenting out lines 43-45 in unix/mblogin.c /***** OBSOLETE !!! #if defined(__NetBSD__) #undef HAVE_UTMPX_H #endif ******/ Since I am not familiar with the long, distant history of NetBSD I suppose that this piece of code originates from at least 2018. Since compiling the code now works without these directives, chances are that something changed "under the hood" of NetBSD.
Update: I've been able to fix this issue by commenting out lines 43-45 in unix/mblogin.c /***** OBSOLETE !!! #if defined(__NetBSD__) #undef HAVE_UTMPX_H #endif ******/ Since I am not familiar with the long, distant history of NetBSD I suppose that this piece of code originates from at least one decade ago. Since compiling the code now works without these directives, chances are that something changed "under the hood" of NetBSD.
Compiling on NetBSD (10.x) fails
mbsebbs v1.1.1
Updated source.de and germandu.txt language source files
Note that format for mbmsg is : po post <from> <to> <#> <subj> <file> <flavor> Post file in msg area # </flavor></file></subj></to></from> Yes for p=1 -3, are in quotes although I have not tried using single quotes.
mbmsg post command not functioning properly
mbmsg post command not functioning properly
mbmsg post command not functioning properly
mbout "stair stepping" its output when called from another program
scripts folder and content missing in 1.1.1
The tarball in the Files section has been replaced.
The script and html folders are both present in the Git repository. I will verify the tarball in the files section and replace it if needed.
Add to that there is no HTML folder as well so there could be more missing.
scripts folder and content missing in 1.1.1
Update README to current version.
config.status: error: cannot find input file: `html/index.html.in'
Fixed in v1.1.1.
config.status: error: cannot find input file: `html/index.html.in'
Fix building distribution tarball.
Add missing ChangeLog_2024.
v1.1.1 - Updated HTML Documentation
Remove surplus files.
Fix build errors created by updated HTML documentation.
This is a known issue with Sean's last update to the docs. I'm working on a fix. Andrew On Mon, Mar 24, 2025 at 1:18 PM lodger niels@users.sourceforge.net wrote: Dito, I ran into the same problem but was able to work around that issue by downloading the tar.bz2 file of version 1.0.9 and copy over the following files from that archive: html/index.html.in html/basic.html.in html/upgrade.html.in I guess those files were removed from the repo by accident. [tickets:#55] https://sourceforge.net/p/mbsebbs/tickets/55/...
Dito, I ran into the same problem but was able to work around that issue by downloading the tar.bz2 file of version 1.0.9 and copy over the following files from that archive: html/index.html.in html/basic.html.in html/upgrade.html.in I guess those files were removed from the repo by accident.
Still present on current version 1.1.0
Non-Sysop users can only delete a message when they are the sender of that message, but not the recipient
make install fails (MBSEBBS v1.0.9)
Do you know that v1.1,0 was released some time ago ? It is available via the GIT repository OR via Fido area MBSEBBS as MB110.ZIP This file has only beenc reated / uploaded to all downlinks in the last 2 hours.
I resolved this by removing the entire /opt/mbse directory, removing mbse & bbs users, rebooting, then performing a fresh install of mbsebbs-1.0.9.tar.bz2
make install fails (MBSEBBS v1.0.9)
config.status: error: cannot find input file: `html/index.html.in'
Updated HTML manual
mbsebbs v1.1.0
with '#' will be ignored, and an empty message aborts the commit.
There is good news - I found at least a workaround for now. In Ubuntu 24 they increased security levels a lot, see here: https://ubuntu.com/blog/whats-new-in-security-for-ubuntu-24-04-lts One of the issues is preventing buffer overflows. Setting the compiler flag -D_FORTIFY_SOURCE to "1" instead of default value "3" fixes the problem, mbse is running fine. Of course, this does not fix the root cause of the problem. However, I fully understand that limited ressources are an obstacle for a quick fix....
Yes you can ingore the one's with trying to fit larger source into smaller targets. I get them all the time and doesn't affect the programs working - at least at my end. I agree that this kind of error/warning should be fixed but all of the coders involved in mbse work mostly full time and for me at 78 in June I am getting too long in the tooth - mentally at least - looking at my own programming even in Cobol - just a lot slower than I used to be, ditto errors in my coding :( So ignoring that type...
Thanks for your quick answer - I downloaded 1.1.0 and compiled it, however with the same result. There are lots of warnings "‘warn_unused_result’ [-Wunused-result]" in build.err, and few warnings like: pktname.c: In function ‘prepbuf’: pktname.c:113:38: warning: ‘%03x’ directive output may be truncated writing between 3 and 8 bytes into a region of size 7 [-Wformat-truncation=] 113 | snprintf(zpref, 8, ".%03x",addr->zone); As I'm not a c++ programmer I can't tell if these warnings are relevant for...
BTW, gcc version is gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0 Copyright (C) 2023 Free Software Foundation, Inc.
Forgot to say - As I no longer have authority to upload the latest code archives I have not kept the files section up to date.
Please try using 1.1.0 as taken from the GIT code sources and advise. No mention of code changes to mbfido has been mentioned though. When building mbse do a make > build.log 2>build.err checking .err first then look at .log for any errors or significant warnings.
mbfido buffer overflow
Write the BBS software/version to door32.sys instead of the BBS name.
Restore removed ChangeLog_2023
Add Linux Mint support to SETUP.sh
Add support for setting a password on the bbs (newuser) account to enable new
Remove obsolete BBS list menu from example menus/textfiles. Correct URL for