EXODUS Knowledge

TMUX Screens

To create the EXODUS maintenance/programming environment

exodus#: ./tmux.exodus

Screens

0: /
    General work for server services/configs. i.e /etc/nagios, /etc/apache2, /var/log/mail.log or general networking.

1: /root/exodus/
    Exodus core is installed. Contains build and make libraries here ./libexodus

2: /root/exodus/libexodus/exodus
    Core exodus library source code which emulate the AREV system e.g var.cpp
    
3: /root/exodus/cli/src
    Exodus Command Line Interface E.g edir, edic, list, listfiles, delete, createdb, deletedb.
    
4: root/exodus/service
    EXODUS core default host directory but also contains scripts that create/manage requirements of a service (create_service, create_db, create_site, backup_db, restore_db, start, stop, status)
    The www/3/exodus has generic .htm, php and .js which provide basic website functionality i.e Login page, Support Menu, User details, Authorization.
    NEOSYS www files linked into ./www, from /root/neosys/web, which pulled from NEOSYS www git.

5: /root/exodus/service/src
    Exodus core service programs (programs that are not related to NEOSYS agency operations and can be used to support other non-NEOSYS services) eg listen, usersubs, sendmail, openfile, select, sort, list,.

    Extra info:    
    The dat/ has generic dictionary files. (See Section Dictionaries & Psql Functions)
    TODO: compall currently throws few warnings. Read them and familiarise. In case new warnings appear, notify Steve.    
        
6: /root/neosys
    NEOSYS specific client installation & management scripts e.g .doall, import_db and import_files (from AREV), ./run ./test (see below for these two commands)
    
7: /root/neosys/src
    NEOSYS Agency programs (see section How AREV programs are distributed in EXODUS src/*.cpp
    /root/neosys has the neosys .git

8: /root/hosts
    client specific files  e.g logs, images, (shared ./www -> root/exodus/service/www

9: /root/exodus/test/src
    series of programs that test whether subroutines (specifically Exodus core libraries) work as they should eg for the var lib - "assert( var("11111").isnum());"

10: bash /bin/top
    Monitor for NEOSYS client processes
    Displays customised format: sorted by total time spend and by processor time.
     Press "=" : to change to standard top format
     Press shift + w : to save format settings, replacing the old customised top format
     To go back to the customised format do:
        Press "o"
        Type "COMMAND=serve_agy"
        shift + t : this sorts by total time spent
        shift + p : this sorts by processor time
        shift + w : to save this setting and enter  'y' to confirm

11: /var/log/syslog
     Log of NEOSYS client requests

12: /root/exodus/service/quick
     Displays the last time the svr file (in /root/hosts/<client>/data/<dbname>) was updated.

Object Code/Libraries

LIVE and TEST processes use different sets of object code. TEST processes use libraries in ~/lib/, whereas LIVE processes use object code in ~/neo/lib

This means development & testing can be done stress free on TEST database, as opposed to testing on production databases.

When compiling using edic, the TEST object code is updated if the compilation is successful. (~/lib)

Dictionaries & Psql Functions

Dictionaries - data used to describe other data; specifically the fields of other files.

There are three types of fields:

(F) Field for raw data E.g "Office 44 Building Rush"
(S) Symbolic or calculated E.g for total ans=field1+field2
(G) General or Group E.g "@CRT" which contains always contains the default columns to show on the output of the list program; if no columns provided in list command.

Show dictionary using "EXO_DATA=test list dict.clients".

Development and deployment using 'dat' files

Rationale

Part of system development is the creation of various data that is neither programs nor layout i.e. not cpp, h, html, js, php files etc.

For example:

• Dictionaries are data about data.
• Language files are data about text to use for various languages.
• “Change logs” are data about changes in the system.

Historically, in EXODUS and NEOSYS, the above data has been deployed in exodus database files using SQL text files. However SQL files are not convenient for development.

Therefore, 'dat' text files will be used now so that standard development tools including editors and git can be fully exploited.

'dat' files

Each database file is represented by an os directory of the same name.

Each record in the database file is represented by an os text file where filename is the primary key.

For example a record with key DEADLINE in a dat file dict.materials would be represented as an os text file dat/dict.materials/DEADLINE

Each line in the os text file represents one field in the db record. In other words, db record FM characters are represented by new line characters in 'dat' files. Any actual new line characters required in the record, and any backslashes, are escaped and appear as '\n' and '\\' in 'dat' files. Other database field separator characters such as VM, SM, TM and STM are stored without any conversion.

Location of dat files

The development versions are stored in exodus and neosys src/dat dirs. They form part of the standard git repositories in parallel with cpp files.

The operational versions are stored in ~/dat and ~/live/dat alongside bin and lib dirs and are automatically installed into databases as database files on service startup. Any database functions embedded in the text files (pgsql) are also automatically installed at the same time.

Delete Database dictionary file

cli syncdat deletes database files if the dat dir is empty or contains a file 'SYNCDAT_DELETE'

touch neosys/src/dat/dict.users/SYNC_DELETE
neosys/src~: syncdat

Editing and deploying a 'dat' file

It is currently a three step process to edit and deploy such 'dat' files.

Edit the 'dat' file (i.e dict.file record)

Note that EXODUS service and NEOSYS service have different src/dat folders.

Editing language items:

edir dat/alanguage/SCHEDULES*ARABIC

Editing a dictionary item:

edir dat/dict.materials/DEADLINE

Editing a pgsql function in a dictionary:

edir dat/dict.materials/DEADLINE 8

Copy all 'dat' files to ~/dat

This step might be removed at a later date.

This will cause all test databases to immediately restart and load any 'dat' file changes into dictionaries and data files and also create any new or modified pgsql functions.

If any ~/neosys/src/dat files were edited:

cd ~/neosys/src

./compall dat

and/or, if exodus/service/dat files were edited

cd ~/exodus/service/src

./compall dat

Copy all programs and 'dat' files to ~/live/bin|lib|dat

This should only be run after testing. It will cause all live databases to automatically restart and do the same as the test databases mentioned above.

cd ~/exodus/service

./copyall CONFIRM

Delete dat record

Simply open the corresponding dat file, remove all lines and save.

Psql unaccent extension

The unaccent extension and the immutable_unaccent function are created in the db ‘template1’ during exodus installation while user is postgres which is a superuser.

Thereafter all new databases are created as copies of template1 so they contain the extension and function

Error

MVDBException:ERROR: function immutable_unaccent(text) does not exist
ERROR:  permission denied to create extension "unaccent"
HINT:  Must be superuser to create this extension. 

Solution

sudo -u postgres psql -c 'ALTER USER exodus WITH SUPERUSER;'

Processes

The TEST process for all database use the same object code stored in /root/lib, whereas all LIVE process use the object code in /root/neo/.

Postgres

Connect into postgres shell:

alias psql='sudo -u postgres psql'

Delete a database:

sudo -u postgres dropdb <dbcode>

Debugging Exodus

Debugging Live/Test services

./test <dbname> - execute test programs on _test database.

./run <dbname> - execute test programs on live database.

Debugging var values

Explanation of var flag value in gdb debug mode.

(gdb) p varx                                                           
$2 = {var_str = "", var_int = 0, var_dbl = 0, var_typ = {flags_ = 2}}

Each exodus var object contains 4 variables of type std::string (var_str), int (var_int), long double (var_dbl) and another int (var_typ i.e flags).

The first 3 bits of var_typ (flags_) are used to signify which of the other variables are assigned.

First bit = string is un/assigned. Second bit = int is un/assigned. Third bit = double un/assigned (a combination of these bits describes whether var_str/ var_int/ var_dbl are assigned.

Examples:

000 (binary) = 0 (decimal) = non are assigned.

100 (binary) = 1 (decimal) = var_str is assigned. (var_int & var_dbl are not)

010 (binary) = 2 (decimal) = var_int is assigned. (var_str & var_dbl are not)

001 (binary) = 4 (decimal) = var_dbl is assigned. (var_str var_int are not)

Combinations:

110 (binary) = 3 (decimal) = var_str & var_int are assigned. (var_dbl is not)

To inspect a “common” variable

e,g, a variable called ba.ledgern

p ((subExodusProgram::ba_common)ba).ledgern

To inspect a common block

e.g. a common block ba

ptype (subExodusProgram::ba_common)ba

To dump all variables in a common

e.g all variables in ba

p (subExodusProgram::ba_common)ba

What types are available in a program?

info types common
info types subExodus
info types libexodus

Other commands

explore subExodusProgram::ba_common

Process Hung or consuming +100% CPU

If process is consuming +100% CPU then it is likely stuck in an infinite loop.

./doall <CLIENT> stop

./run <CLIENT> 

./test <CLIENT>

Search through recent logs for <CLIENT> looking for requests that didn't return OK at the time nagios alerted of Hung process.

A user may also instigate the error again, so monitor the CLIENT's service CPU usage.

If cause found recreate it in test and once test process hit +100% break in test debugger.

If cause not found, you will have to continue checking logs for the request that caused it or hope a user recreates the issue in live debugged service.

Once you've broken in the debugged with the error, enter "n" and hold the enter key until you just seeing line repeat.

Pay attention to start of loops code. E.g WHILE or FOR. (there is likely an error is there)

./doall

General

~/neosys/doall [LIVE|TEST] <DBCODE|ALL> < ACTION [OPTIONS,..] | bash -- COMMAND ]

Example:

./doall TEST ALL create_site t-

Result: Create site for ALL TEST databases, using domain name prefix option "t-".

Screen 6: ./doall script contains all the necessary information(codes) to setup an installation. It includes scripts to backup, restore, create an Apache site, create/start/stop/status a service, import an AREV database into postgres and more.

backup_db

• Does a backup & restore of a LIVE database into the corresponding TEST database.
• Backup <dbcode>.sql file is written to /root/backups/sql; which is rsynced to nl19:/backups/current/exodus/
• Unlike AREV, postgres can perform a "backup" of a database whilst the system is in use.

Git

There are two repositories, one for EXODUS and the other for NEOSYS.

Using git to make changes

Before following steps you must have a tested updated to a program/file/script. Do not commit untested changes to avoid a messy git history of reverts.

Update your local repo before committing to local repo using the g alias for "git pull --ff-only ; git push && git status'":

g

Check which updates/files have not yet been staged and/or committed: Add your updates to the staged area:

git add <filename>

or if all the changes made need to be staged:

git add -a

Make a commit with a descriptive message on purpose of updates:

git commit -m <description n purpose of changes>

Again use g alias:

g

Other useful git cmds

Do not use this commands unless you know what WILL happen.

• git pull - Instead use the safe "git pull --ff-only"

Stick to the alias "g" which does "git pull --ff-only ; git push && git status'"

• git log - display history of commits to master branch
• git diff - display the differences in files between working files and files in local repo.
• git status - display: which updated files are staged/not staged(tracked)
• git stash -
• git branch - switch to a new branch
• git branch <branchname> - will switch to this branch only if it exists
• git checkout - DESTROYS/Updates the state of local working directory with the state of the files in the local repo. (YOU WILL LOSE non staged updates)
• git restore <filename> - DESTROYS/Updates the file with the version in the local repo. (like with git checkout but for a specific file)
• git checkin -
• git revert <commitHash> - reverses a specific commit (use git log to get the chosen commit hash)
• git ..

Converting AREV programs to EXODUS

Decompile AREV to C++

Do in Master AREV Installation Maintenance mode: (win7)

1. ATTACH ADECOMC
   • ADECOM <programname> *single program
   • ADECOM <prog1> <prog2>
   • ADECOMALL *all programs (CHECK FIRST)

Include the option "(V)" in the command to print the C++ to a notepad, which can easily be copy and pasted.

Getting C++ program to Exodus Installation

Two methods: (use the first for one off programs)

Copy & Paste

Compile program and open source code in notepad

ADECOM <programname> (V)

Find which directory the program belongs. e.g fin/med/job/sys e.t

find /cygdrive/d/exodus/pickos | grep <program name>

If cpp in SYS, the program belongs in ~/exodus/service/src OR if in MED JOB FIN GEN AGY the program belongs in ~/neosys/src

Copy the source code in the text file from the first command.

In Exodus, create a new .cpp (in correct directory) and paste the source code.

Compile & Test

Rsync

/d/exodus/arev/syncup.sh

If cpp in SYS then: ~/exodus/service/src ./getpickos

If cpp in MED JOB FIN GEN AGY then: *~/neosys/src

Compile C++ files to TEST system

1. • ./test <DBNAME>
   • ~/neosys ./doall TEST <DBNAME> restart #to get one service to start start using the new lib files
   • ~/neosys ./doall TEST all restart #to get all the services to start start using the new lib files

Install C++ files to LIVE System

1. ~/exodus/service/ ./copyall #to copy all the ~/lib and bin files to ~/live/lib and bin ... which is used by all exodus/live services

Writing Standard Exodus Core Function/Method Testing

Screen 9: ~/exodus/test/src/ There are a series of test programs that check whether methods/functions behave as intended. They do this using the function, assert.. a 1 or more argument values produce one and only one output)

e.g test_multilang.cpp or test_sort.cpp

Two methods of running test programs:

• Screen 9: make test
• after compiling using edic/compile/c, enter test_prog_name. (Since compile has moved it to ~/bin)

Difference between the two methods is make calls gdb directly; whereas ~/bin/test_prog_name uses exodus compile program

1. ~/neosys ./doall LIVE all restart

Upgrading Exodus

1. Develop patch in Dev system

Patching neosys/src or exodus/service/src

1. Manually insert patches and compile into test programs.
2. If patch dat files then run neosys/compall to get dat files into ~/dat

• If Patsalides:
  1. SITE_DIR=ptcy ./test basic
  2. login to BASIC_TEST and test
• Other clients:
  1. ./test DBCODE
  2. login to DBCODE and test patches works

1. run exodus/service/copyall and check only the patched programs are listed. (if not, see Troubleshoot below)
2. Inform users to log off for 10mins. As a rule of thumb, live services must be stopped before copying test programs to live.
3. exodus/service/copyall CONFIRM

Troubleshoot

./copyall lists programs you have not patched

Use exodus/service/copyone to copy only your patched programs one by one. (./copyone will not copy dat files)

Upgrading to new version

READ: remember there is no test version of libexodus programs. This means that if libexodus programs are compiled and installed, neosys/src and exodus/services LIVE programs MUST BE UPGRADED.

1. Upgrade test system to test
   1. If a dev system like de2, git stash any uncommitted changes other staff may be working on.
   2. Run "g" in ~/exodus (to do git pull --ff-only)
   3. Run "m" in ~/exodus (to compile and install libexodus)
   4. Run "~/neosys/upgrade.all.sh live" in ~/neosys (to upgrade exodus/service and neosys/src live programs)
   5. Begin testing
2. Upgrade clients
   1. • Client hosted - Schedule a planned upgrade with client.
      • NEOSYS hosted - Inform all clients/users of planned morning upgrade, 24hours in advanced. (TODO: 'What's New in NEOSYS') AND (emailallusers.cpp)
   2. Day of upgrade, check USB backup was successful & make a container snapshot, otherwise do not proceed.
   3. Stop services
   4. Run "g" in ~/exodus (to do git pull --ff-only)
   5. Run "m" in ~/exodus (to compile and install libexodus)
   6. Run "~/neosys/upgrade.all.sh live".
   7. Check services started automatically without issues.
3. Inform users their system has been upgraded and they can login.

Roll Back Upgrade

If for any reason the entire upgrade needs to be reverted (excludes clients database), follow steps below:

1. Inform users that there is a problem and services need to be stopped.
2. Stop all exodus processes.
3. Restore the morning's USB backup by: (Note this backup contains: source/obj code, /etc, neosys scripts but not client data)
   1. Login into container's host and rsync the morning's usb backup to the container's /:

   • rsync --dry-run -avz -e 'ssh -p <C_SSHPORT>' /backups/usb/<C_CODE> <C_CODE>:/      (Example: rsync --dry-run -avz -e 'ssh -p 19582' /backups/usb/ad1 ad1:/

     )
4. Quick sane check, the latest git commit is not the latest git commit in the remote repo.
5. Inform users they can login.

Configuring services to autostart during login

For PTCY,

1. Create a file 'autostart.cfg' in the data folder

touch /root/hosts/<dbname>/data/autostart.cfg

This will autostart a database service as long as at least one database service in that directory is running.

For example, demo service will autostart during login if,

1. /root/hosts/demo/data/autostart.cfg exists and
2. demo_test service is running

Speedup postgresql importing databases

Can be sped up by a factor of 10 BUT may result in corrupt files in case of hard OS crash where the dirty memory is not flushed to storage.

Therefore it is advisable to use this feature only briefly and REMEMBER TO REMOVE IT!

Email to support@neosys.com whenever using it or use personal notes not memory.

nano /etc/postgresql/12/main/postgresql.conf

Uncomment or add a line

fsync = off

Restart postgres … will break any neosys/exodus running processes.

r postgresql

or reload postgres may also work

Database Attach

root@exodus:~/exodus/cli/src# dbattach
dbattach - Attach foreign database files to the current default database

Syntax is dbattach TARGETDB [FILENAME,...] {OPTION...}

Options:

  F   Forcibly delete any normal files in the current default database.

  R   Detach foreign files
  RR  Remove foreign database connection.
  RRR Remove all foreign database connections and attachments.

  L   List attached foreign files in the current default database

If no filenames are provided then a database connection is created.
This is *required* before filenames can be provided and attached.

Notes:

Attachments are permanent until re-attached or removed.

Indexes on attached files behave strangely.

Issues:

TARGETDB must be on the same connection as the current default database.

Current user must have access to the foreign database.

If EXO_USER and EXO_PASS are not set then exodus defaults are used.

exodus .config file is not used currently.