• Easing "scripted" upgrades

    From Zip@21:1/202 to g00r00 on Sun Mar 1 11:07:08 2020
    Hello g00r00!

    During the recent prealpha testing rounds I've found myself writing some "customized" instructions for upgrading on my system. Basically installing a new fresh copy into /tmp/mystic and then copying/moving/diff:ing files into
    my "real" installation directory.

    Some of the tasks I feel that I "need" to perform on my system could perhaps
    be incorporated somehow into the install or upgrade utility. Some examples would be:

    * Always replacing prompts.dat, assuming that any changes of prompts
    should be performed by having a custom theme and updating the prompts there instead?
    ./install extract prompts.dat /mnt/bbs/mystic/data

    * Updating the docs directory with the fresh one:
    rm -rf /home/bbs/mystic/docs
    mv -i /tmp/mystic/docs /home/bbs/mystic
    find /home/bbs/mystic/docs/ -xdev -type f \( -perm -u+x -o -perm -g+x -o \ -perm -o+x \) -exec chmod a-x '{}' \;

    * Always replacing the default theme, assuming that custom themes should be themes of their own (NOTE that this will unfortunately overwrite any Dispay Order/List ACS settings for the default theme which is a minor nuisance):
    rm -rf /mnt/bbs/mystic/themes/default
    mv -i /tmp/mystic/themes/default /mnt/bbs/mystic/themes
    rm -rf /tmp/mystic/themes

    * Looking for deprecated binaries (manual inspection of output needed):
    find /home/bbs/mystic/ -xdev -mindepth 1 -maxdepth 1 -type f \( -perm u+x -o -perm -g+x -o -perm -o+x \) | while read MYFILENAME REST; do i=${MYFILENAME##*/}; [ ! -e "/tmp/mystic/${i}" ] && echo $MYFILENAME $REST; done

    * Looking for suspected deprecated data directory files:
    diff -r -w /tmp/mystic/data /mnt/bbs/mystic/data | \
    grep -F 'Only in /mnt/bbs/mystic/data' | \
    grep -Ev '\.(aff|bin|cert|des|dfx|dic|dir|info|lnk|ORIGINAL|scn|text)$' | \
    grep -Ev '(dictlist|nodelist)\.txt$' | \
    grep -Ev '(autosig|callers|chatroom|echodata\.[0-9]+|echodupes|echogroup|echonode|histor y|qwknet|users|votes)\.dat$'

    * Looking for new files in the data directory which should be copied to the "real" installation directory (manual inspection of output needed):
    diff -r -w /tmp/mystic/data /mnt/bbs/mystic/data | grep -F 'Only in /tmp/mystic/data' | grep -Ev '\.(ans|dat|txt)$'

    * Replacing *.ORIGINAL files (my naming of original files that I have
    modified) with the new versions, e.g replacing mutil.ini.ORIGINAL with the
    new mutil.ini, so that I can diff those manually later and incorporate any new goodies into my running versions:
    for i in /mnt/bbs/mystic/*.ORIGINAL; do
    i=${i%%.ORIGINAL}; i=${i##*/}; [ -e "/tmp/mystic/$i" ] && mv -f -v "/tmp/mystic/$i" "/mnt/bbs/mystic/${i}.ORIGINAL"; done for i in /mnt/bbs/mystic/data/*.ORIGINAL; do i=${i%%.ORIGINAL}; i=${i##*/}; [
    -e "/tmp/mystic/data/$i" ] && mv -f -v "/tmp/mystic/data/$i" "/mnt/bbs/mystic/data/${i}.ORIGINAL"; done

    * Copying any new (not previously existing) *.dat files to the data directory: for i in /tmp/mystic/data/*.dat; do i=${i##*/}; [ -e "/tmp/mystic/data/${i}"
    ] && [ ! -e "/mnt/bbs/mystic/data/${i}" ] && mv -f -v "/tmp/mystic/data/$i" /mnt/bbs/mystic/data; done
    rm -f /tmp/mystic/data/*.dat

    * Copying any new *.ans and *.txt files to the data directory, unless a corresponding *.ORIGINAL file exists:
    for i in /tmp/mystic/data/*.ans; do i=${i##*/}; [ -e "/tmp/mystic/data/${i}" ] && [ ! -e "/mnt/bbs/mystic/data/${i}.ORIGINAL" ] && mv -f -v "/tmp/mystic/data/$i" /mnt/bbs/mystic/data; done
    rm -f /tmp/mystic/data/*.ans
    for i in /tmp/mystic/data/*.txt; do i=${i##*/}; [ -e "/tmp/mystic/data/${i}"
    ] && [ ! -e "/mnt/bbs/mystic/data/${i}.ORIGINAL" ] && mv -f -v "/tmp/mystic/data/$i" /mnt/bbs/mystic/data; done
    rm -f /tmp/mystic/data/*.txt

    Some of these could perhaps be replaced with new flags to the install or upgrade utility, e.g.:

    ./install syncdocs /home/bbs/mystic/docs
    ./install syncthemes /mnt/bbs/mystic/themes
    ./install deprbin /home/bbs/mystic
    ./install deprdata /mnt/bbs/mystic/data
    ./install newbin /home/bbs/mystic (to extract not previously existing
    binaries)
    ./install newdata /mnt/bbs/mystic/data (to extract not previously existing data files)

    Those are just some loose thoughts.

    I do realize that everyone's setup is different and that mine might be a bit complicated =) as I have my Mystic root in /home/bbs/mystic, have symlinked some .ini files to corresponding files in /mnt/bbs/mystic (on a NAS share), keep *.ORIGINAL files, etc.

    Basically I want to use as much as possible from the latest version (and
    not miss out on any new goodies) and only override certain things.

    All your thoughts on best practice for keeping up-to-date and not missing
    out on anything new -- especially in a scripted fashion -- are most welcome!

    Best regards
    Zip (who actually *does* read upgrade.txt)

    --- Mystic BBS v1.12 A46 2020/03/01 (Linux/64)
    * Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)
  • From g00r00@21:1/108 to Zip on Sun Mar 1 18:11:33 2020
    Some of the tasks I feel that I "need" to perform on my system could perhaps be incorporated somehow into the install or upgrade utility.
    Some examples would be:

    I am trying to move in that direction, where basically a series of commands can be defined to do the upgrade automatically. It gets challenging for a lot of reasons though mostly because it wasn't designed to be upgraded that way and people are resistant to change.

    * Always replacing prompts.dat, assuming that any changes of prompts should be performed by having a custom theme and updating the prompts there instead?
    ./install extract prompts.dat /mnt/bbs/mystic/data

    No one should ever touch prompts.dat (or any files in the data directory, ideally, the editable ones should be available in the configuration).

    prompts.dat is a safe file to automate updating every time if you'd like to
    and I think as part of any automated upgrade this will be included.

    * Updating the docs directory with the fresh one:

    I think in the future the docs directory may just disappear.

    With the Wiki and the ability to export the Wiki to a .txt and .pdf (which we should be able to do using Dokuwiki plugins) we can offer the documentation online via the Wiki and then those exports can be downloaded/distributed separately from the website as well.

    The documentation really needs to be better, its all documented its just sourced all over the place and I think centralizing on the Wiki and exporting from there is probably the best way to get everything in a good place.

    * Always replacing the default theme, assuming that custom themes should

    This one I am not so sure about because I think a lot of people have modified their default themes. Ideally people would probably keep the default as a reference and then create a new theme but that is not the way it has been historically (even I am guilty of that).

    The solution I came up with for this might be to have an online theme repository which will have the latest updated default theme and people can choose to download it if they want to (along with other themes)

    But also having some default themes out of the box and a sync function might not be a bad idea too.

    * Looking for deprecated binaries (manual inspection of output needed):

    Upgrade.exe should handle depreciated data and executable files.

    Some of these could perhaps be replaced with new flags to the install or upgrade utility, e.g.:

    ./install newbin /home/bbs/mystic (to extract not previously existing binaries)

    The way the replace function works, it would add new binaries if they did not exist. I basically hardcode a list of binaries that replace should "replace" even if they don't exist. I gusss replace isn't really an accurate
    description of what it does :)

    --- Mystic BBS v1.12 A46 2020/03/01 (Windows/64)
    * Origin: Sector 7 (21:1/108)
  • From Zip@21:1/202 to g00r00 on Sun Mar 1 14:05:46 2020
    Hello g00r00!

    Thank you very much for your reply!

    On 01 Mar 2020, g00r00 said the following...
    prompts.dat is a safe file to automate updating every time if you'd like to and I think as part of any automated upgrade this will be included.

    Thanks! I'll keep that then. :)

    sourced all over the place and I think centralizing on the Wiki and exporting from there is probably the best way to get everything in a
    good place.

    I agree!

    * Always replacing the default theme, assuming that custom themes sho
    This one I am not so sure about because I think a lot of people have modified their default themes. Ideally people would probably keep the

    Yes, I can imagine that. =)
    The online theme browser/downloader sounds good!
    Perhaps with an option to choose what name to save the theme as.

    Upgrade.exe should handle depreciated data and executable files.

    Thanks! Removing that part from my routine.

    should "replace" even if they don't exist. I gusss replace isn't really an accurate description of what it does :)

    No problem! =)

    Thanks a lot for all the clarifications and for all the work you put into Mystic!

    Best regards
    Zip

    --- Mystic BBS v1.12 A46 2020/03/01 (Linux/64)
    * Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)
  • From Zip@21:1/202 to g00r00 on Sun Mar 1 14:55:05 2020
    Hello again g00r00!

    On 01 Mar 2020, g00r00 said the following...
    I am trying to move in that direction, where basically a series of commands can be defined to do the upgrade automatically. It gets challenging for a lot of reasons though mostly because it wasn't
    designed to be upgraded that way and people are resistant to change.

    Yep!

    Another question -- are .txt and .ans files in the data directory handled in any way by ./upgrade, or only .dat files? E.g. mis_poll.ans which was not present in A45, but is in A46.

    Similarly, does ./upgrade handle (delete) deprecated .txt and .ans files from the data directory, or only deprecated .dat files?

    Just so that I know if I should keep the copying of *.txt and *.ans files and the looking for "orphaned" *.txt and *.ans files in my "quick guide" instructions.

    Thanks again!

    Best regards
    Zip

    --- Mystic BBS v1.12 A46 2020/03/01 (Linux/64)
    * Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)
  • From ryan@21:1/168 to g00r00 on Sun Mar 1 08:47:37 2020
    * Always replacing the default theme, assuming that custom themes sho

    This one I am not so sure about because I think a lot of people have modified their default themes. Ideally people would probably keep the default as a reference and then create a new theme but that is not the
    way it has been historically (even I am guilty of that).

    I'm not a fan of replacing the default theme, because my board will only have one theme, and I'd rather not muck around with maintaining an additional
    theme and forcing everyone onto it. So, I side with g00r00 on this one :)

    --- Mystic BBS v1.12 A45 2020/02/18 (Linux/64)
    * Origin: monterey bbs (21:1/168)
  • From g00r00@21:1/108 to Zip on Mon Mar 2 00:35:10 2020
    Another question -- are .txt and .ans files in the data directory
    handled in any way by ./upgrade, or only .dat files? E.g. mis_poll.ans which was not present in A45, but is in A46.

    If new files are added the upgrade instructions will tell you to do an
    "install extract" for it. They're not there now because its pre-alpha and I
    am not sure if I am going to keep mis_poll.ans or not yet.

    Similarly, does ./upgrade handle (delete) deprecated .txt and .ans files from the data directory, or only deprecated .dat files?

    Yes, it should. Unless I forget lol

    Just so that I know if I should keep the copying of *.txt and *.ans
    files and the looking for "orphaned" *.txt and *.ans files in my "quick guide" instructions.

    The upgrade should always take care of orphans but I do make mistakes so its possible I miss something at some point.

    --- Mystic BBS v1.12 A46 2020/03/01 (Windows/64)
    * Origin: Sector 7 (21:1/108)
  • From Netsurge@21:4/154 to ryan on Sun Mar 1 12:47:44 2020
    I'm not a fan of replacing the default theme, because my board will only have one theme, and I'd rather not muck around with maintaining an additional theme and forcing everyone onto it. So, I side with g00r00 on this one :)

    I agree. Although I would love to have a 40 col theme that supports petscii
    for the c64 users out there, I have made great changes to my default theme
    and don't want to switch people from it.

    |15frank |08// |15netsurge
    |07disksh0p|08!|07bbs |08% |07bbs.diskshop.ca |08% |07mystic goodness |11SciNet |03ftn hq |08% |07https://scinet-ftn.org

    --- Mystic BBS v1.12 A45 2020/02/18 (Linux/64)
    * Origin: % disksh0p!bbs % bbs.diskshop.ca % SciNet ftn hq % (21:4/154)
  • From Zip@21:1/202 to g00r00 on Sun Mar 1 18:55:56 2020
    Hello g00r00!

    If new files are added the upgrade instructions will tell you to do an "install extract" for it. They're not there now because its pre-alpha

    Thanks! Skipping my manual copying of them.

    Yes, it should. Unless I forget lol

    :-)

    The upgrade should always take care of orphans but I do make mistakes so its possible I miss something at some point.

    No problem! Again, thanks!

    Best regards
    Zip

    --- Mystic BBS v1.12 A46 2020/03/01 (Linux/64)
    * Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)
  • From Vk3jed@21:1/109 to ryan on Mon Mar 2 09:16:00 2020
    On 03-01-20 08:47, ryan wrote to g00r00 <=-

    * Always replacing the default theme, assuming that custom themes sho

    This one I am not so sure about because I think a lot of people have modified their default themes. Ideally people would probably keep the default as a reference and then create a new theme but that is not the
    way it has been historically (even I am guilty of that).

    I'm not a fan of replacing the default theme, because my board will
    only have one theme, and I'd rather not muck around with maintaining an additional theme and forcing everyone onto it. So, I side with g00r00
    on this one :)

    While for me, replacing the default theme is actually a good idea. Maybe this is an option we need for the upgrade process?


    ... A steak pun is a rare medium well done.
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)
  • From Avon@21:1/101 to ryan on Mon Mar 2 12:25:56 2020
    On 01 Mar 2020 at 08:47a, ryan pondered and said...

    This one I am not so sure about because I think a lot of people have modified their default themes. Ideally people would probably keep th default as a reference and then create a new theme but that is not th way it has been historically (even I am guilty of that).

    I'm not a fan of replacing the default theme, because my board will only have one theme, and I'd rather not muck around with maintaining an additional theme and forcing everyone onto it. So, I side with g00r00 on this one :)

    I am in the same boat with the default being the customised one.. I'm
    thinking when the day comes to do a fresh install and a bunch of painstaking migration that's when I will ensure default is truly default.

    --- Mystic BBS v1.12 A46 2020/02/29 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)