Whilst trying to setup nightly maintenance I came across the option to
purge the user DB for inactive users, as well as the option to pack it (whatever that means).

Anyway.. attempting to purge reports back with an error stating that the
value cannot be less than 7 (but it's set to 180), and packing reports
that it cannot open the user DB.
The permissions seem to be fine (reading "rwxrwxr-x"), so what is going
on here? Also what does packing the user database mean?

¿ÚÂÄ ³ CatX, ³ . . . . . . . . . .
ÃÁ´. ³ SysOp Of ³ . . : . : . : . : . .
³ ÀÙ ³ Trigonia ³ . : . : . .

--- Mystic BBS v1.12 A41 2018/12/27 (Linux/64)
* Origin: Trigonia (21:1/197)

Anyway.. attempting to purge reports back with an error stating that the value cannot be less than 7 (but it's set to 180), and packing reports that it cannot open the user DB.
The permissions seem to be fine (reading "rwxrwxr-x"), so what is going
on here? Also what does packing the user database mean?

It sounds like the ownership could be wrong. I am assuming it not reading the 180 because it doesn't have access to do it or there could be a typo (or of course a bug). There isn't really a good way to evaluate without seeing the .INI settings and the ownership.

As far as packing the user file, this removes deleted user records and associated data. When you flag a user as deleted they still stay in the system, allowing you to undelete them in the user editor if you want.

But when you pack the user database, it does the following to each deleted user:

- Physically removes the user from the user database
- Removes any draft messages they've saved
- Removes private messages sent or received to the user.
- Removes the users "last read" and "last file scan" data

--- Mystic BBS v1.12 A42 2019/01/25 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

It sounds like the ownership could be wrong. I am assuming it not
reading the 180 because it doesn't have access to do it or there could
be a typo (or of course a bug). There isn't really a good way to
evaluate without seeing the .INI settings and the ownership.

The .ini looks alright to me (I've posted part of it at the end of my
message), so I'm assuming it must either be a ownership issue or a bug
then.

Since I had to chmod the entire mystic root after the upgrade to A41 (it wouldn't read the userDB otherwise due to the permissions not allowing
it), that would most likely be the case.

For now I've done a recursive chmod with a security bit of 777
(rwxrwxrwx), and I'll try if it works after sending this message. (I need
to be logged out or else it won't let me purge the userDB.)

Due to security reasons 777 is obviously not a very good setting, what
should I apply instead? What would the absolute minimum permissions be for mystic and it's utilities, while still letting them be fully operational?

As far as packing the user file, this removes deleted user records and associated data. When you flag a user as deleted they still stay in the system, allowing you to undelete them in the user editor if you want.

But when you pack the user database, it does the following to each
deleted user:
- Physically removes the user from the user database
- Removes any draft messages they've saved
- Removes private messages sent or received to the user.
- Removes the users "last read" and "last file scan" data

Okay so since both of those were about packing the userdb I'm assuming the first one was about purging the userdb, whilst the second one was about
packing it, is that correct? (Spelling mistake?)


; beginning of maint.ini -------------------------------------------------

PurgeUserBase = false

; (more options here)

[PurgeUserBase]

; Mark users for deletion that haven't called in days.
; This value cannot be less than 7

days = 180

; end of file ------------------------------------------------------------

¿ÚÂÄ ³ CatX, ³ . . . . . . . . . .
ÃÁ´. ³ SysOp Of ³ . . : . : . : . : . .
³ ÀÙ ³ Trigonia ³ . : . : . .

--- Mystic BBS v1.12 A41 2018/12/27 (Linux/64)
* Origin: Trigonia (21:1/197)

Since I had to chmod the entire mystic root after the upgrade to A41 (it wouldn't read the userDB otherwise due to the permissions not allowing it), that would most likely be the case.

chmod does not change ownership, it just sets whether a file can be read, written to, or executed. What you should be looking at is chown to set the "owner" of the files to whatever user you want to have executing mystic and then you start Mystic as sudo.

Something like "sudo chown -R bbsuser:bbsuser /mystic" where bbsuser is whatever your bbs user is.

--- Mystic BBS v1.12 A42 2019/01/31 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

On 31 Jan 2019, g00r00 said the following...

chmod does not change ownership, it just sets whether a file can be read, written to, or executed. What you should be looking at is chown to set the "owner" of the files to whatever user you want to have executing mystic and then you start Mystic as sudo.

Actually he is correct.. I had to chmod the /mystic/data folder to 777
because of wrong file permissions .. It has to do with the new files added
in a41 when they do a fresh install

--- Mystic BBS v1.12 A41 2018/12/27 (Linux/64)
* Origin: internal dimension + idbbs.dlinkddns.com:2019 (21:1/178)

chmod does not change ownership, it just sets whether a file can be r written to, or executed. What you should be looking at is chown to s the "owner" of the files to whatever user you want to have executing mystic and then you start Mystic as sudo.

Actually he is correct.. I had to chmod the /mystic/data folder to 777 because of wrong file permissions .. It has to do with the new files
added in a41 when they do a fresh install

No, they're not correct. Sure this might have solved your problem but it doesn't make it the right thing to do - its sort of like a bandaid when the real problem is the wound. :) Let me try to explain a little bit:

What you are doing with chmod 777 is telling Linux that anyone can do anything with those files or folders that you chmodded, regardless of who owns the files. If it didn't work before you did that, its almost certainly because your ownership was wrong (which chown changes).

An example of how this could play out:

Someone has a Raspberry Pi and they forget to change/disable the default Pi account. They set up their Mystic BBS and its running, but they still have their SSH server running and the default Pi account active. Someone logs into SSH via that account and since the BBS files were chmod 777, the Pi user downloads the user database, and then deletes their entire BBS.

Without chmod 777 that Pi user would never be able to access the BBS
directory or files because they were not the owner of the Mystic directory or files.

--- Mystic BBS v1.12 A42 2019/01/31 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

On 01 Feb 2019, g00r00 said the following...

No, they're not correct. Sure this might have solved your problem but it doesn't make it the right thing to do - its sort of like a bandaid when the real problem is the wound. :) Let me try to explain a little bit:

What you are doing with chmod 777 is telling Linux that anyone can do anything with those files or folders that you chmodded, regardless of
who owns the files. If it didn't work before you did that, its almost certainly because your ownership was wrong (which chown changes).

Even chmodding the /mystic folder to the BBS user did not fix the problem because a couple files in /data were not writable by anyone other than root.
I changed it to 750 on the folder and 644 on the files so the files can only
be accessed by the owner

--- Mystic BBS v1.12 A41 2018/12/27 (Linux/64)
* Origin: internal dimension + idbbs.dlinkddns.com:2019 (21:1/178)

On 02-01-19 10:31, g00r00 wrote to Night Stalker <=-

What you are doing with chmod 777 is telling Linux that anyone can do anything with those files or folders that you chmodded, regardless of
who owns the files. If it didn't work before you did that, its almost certainly because your ownership was wrong (which chown changes).

An example of how this could play out:

A good warning for Linux newbies. I try and have each user own no more than they need to. On my Pi, there's 2 BBSs. Synchronet's tree is owned by one user, while Mystic's is owned by another user, and permissions are set at 0755 for directories and 0644 for files other than executables (which are 0755). So each BBS can't write to the other. No need to, they exchange data using binkp, etc. :)


... Old hitchhikers never die-they just throw in the towel.
=== MultiMail/Win v0.51
--- SBBSecho 3.03-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)

On 02-01-19 13:18, Night Stalker wrote to g00r00 <=-

Even chmodding the /mystic folder to the BBS user did not fix the
problem because a couple files in /data were not writable by anyone
other than root. I changed it to 750 on the folder and 644 on the files
so the files can only be accessed by the owner

I recursively chown my Mystic folder to the Mystic user when I upgrade (done by the script that does the repetitive part of the upgrade), so there's no files owned by root or anything else, which solves that problem. I did get caught out when upgrading to A40, because I had to manually upgrade the user database and did that as root, causing the upgraded database to be owned by root. Oops. :)


... A bad day: "Transfer completed (5720468 bytes, 1 CPS)"
=== MultiMail/Win v0.51
--- SBBSecho 3.03-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)