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 & 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, pending
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.
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
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
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
~/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)
- 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
- ./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
- ~/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
- ~/neosys ./doall LIVE all restart
Upgrading Exodus
- Develop patch in Dev system
Single Patches
- Insert patches into various files and compile if necessary
- If patch dat files then run neosys compall to get dat files into ~/dat
- If Patsalides:
- SITE_DIR=ptcy ./test basic #requires /etc/systemd/system/agy_test@.service to have been patched like agy_live@.service
- web login to BASIC_TEST to test
- If not patsalides
- ./test DBCODE
- login to DBCODE and test
- If all ok
- ./copyall
- CHECK what WILL be copied!
- Judge if really need to get people off (unlikely for typical patch) and request users to logout for 10 mins
- ./copyall CONFIRM and CHECK what was copied is as per exceptions same as previous step
- ./copyone could be used instead of copyall but it has no test mode and does not copy dat files
Upgrading to new version
Use when there are too many changes to do individually patches.
- 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)
- 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.
- Check upgrade works on test service using:/root/neosys/upgrade.all.sh test
- Check the latest patch is working.
- Run/root/neosys/upgrade.all.sh live
- 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:
- Inform users that there is a problem and services need to be stopped.
- Stop all exodus processes.
- Restore the morning's USB backup by: (Note this backup contains: source/obj code, /etc, neosys scripts but not client data)
- 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:/
)
- Quick sane check, the latest git commit is not the latest git commit in the remote repo.
- Inform users they can login.
Configuring services to autostart during login
For Ptcy.
- 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,
- /root/hosts/demo/data/autostart.cfg exists and
- 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.
