EXODUS Knowledge

TMUX Screens

To create the EXODUS maintenance/programming environment

exodus#: ./tmux.exodus

Screens

0: /
    Work regarding exodus server. i.e /etc/nagios or general networking or /var/log/mail.log

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

2: /root/exodus/libexodus/exodus
    Core exodus (libraries that emulate the AREV system e.g mv.h )
    
3: /root/exodus/cli/src
    Exodus Command Line Interface e.g edir, edic, list, listfiles, delete, createdb
    
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)
    One exception is NEOSYS www files are in ./www, 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:    
    sql directory contains basic dictiorary files converted to sql instructions used when creating a EXODUS psql database
    e.g dict_voc.sql is a file that describes what to expect in certain fields of the voc file.
    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
    ../ has .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) In order to apply a tested patch to LIVE see Update LIVE programs.

Dictionaries

Dictionaries, the files used to describe the fields of a file's record. Unlike in AREV, there is a copy of all dictionaries in each pgsql database (In AREV, updating a dictionary would affect all the databases).

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 3 variables of type string, int and double.

All 3 may be unassigned or only the string be assigned or just the int and double e.t.

You can tell which variable type of a var object are set based on the var's flag value.

1 = Means the string is assigned 2 = Means the int is assigned 4 = Means the double is assigned

Example: If the flag is 7 (1+2+4), then all types are assigned.

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

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

Updating a pgsql function in an exodus dictionary

PENDING

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.

Editing and deploying a 'dat' file

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

Edit the 'dat' file

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

​

Upgrading Exodus

1. Inform clients.
   • 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. If the morning's USB backup failed, do NOT continue upgrade procedure because if upgrade fails, we need a way to roll back system to last working state.
3. Check upgrade works on test service using:/root/neosys/upgrade.all.sh test
4. Check the latest patch is working.
5. Run/root/neosys/upgrade.all.sh live
6. 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

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