System administration includes all processes to keep the application running during the application life cycle.
SysAdmin tasks include:
Operations & Maintenance processes are necessary to keep a software application up and running. The complexity of these processes varies with the size of the company:
Operations & Maintenance for SOHO and Small Companies can be reduced to the use of the ASUS (Automatic Software Update Service) that will be available in one of the next releases.
The figure above provides an overview over all processes covered in this manual. The processes will be explained one-by-one in the following chapters.
The figure shows roles interacting with technical items such as the software application and hardware.
The figure above uses several "roles" to describe the responsibilities of the people related to a with ]project-open[ system:
Also the following symbols are used in the figure above to refer to several types of servers:
The figure above represents three different servers that are used during the lifecycle of a ]project-open[ application:
As a code repository, ]po[ uses CVS (Concurrent Versioning System). The repository is mirrored nightly to github.
Please see About Upgrades
Please find additional information at About Developers
The "staging" process has the purpose to create a testing environment on the STAGING Server that is as close as possible to the PRODUCTION Server. Staging consists of two steps:
Executing Steps 2a and 2b:
A "Tester" performs testing on STAGING and verifies that the application is running correctly. Afterwards the staging process is repeated on the PRODUCTION server.
"Productive Setting" is a repetition of the staging operation on the production server.
Helpdesk operations assure you that all of your users can use the system productively. In general you want to optimize the following parameters:
The best practice to optimize this reaction time / cost ratio is to use a staged system of:
Default locations:
For log rotation please add the following lines to either 'root' or 'projop' crontab
# Force logrotate every hour in order to keep logs small 49 */2 * * * /usr/bin/killall -HUP nsd
[tbd.]
]project-open[ has been developed primarily using PostgreSQL as the database back end for information storage and retrieval.
There are three different options available for the coupling relationship that links ]project-open[ to PostgreSQL.
PostgreSQL security configurations are controlled by a config file located at:
The default configuration ]project-open[ uses is:
# TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD local all all trustIn this configuration, the database will allow full access to all data for all local users of the server computer while blocking the access for anybody not working locally on the computer. This setup is very convenient for our ]project-open[ demo server where we cannot predict the name of the local users. However since you will more than likely be able to know every user involved and using ]project-open[ (your list of employees and customers) you may want to change these settings for a productive installation.
Please see the PostgreSQL documentation for more details.
To create a new backup please go to your ]po[ applicationās Admin -> Backup menu and click on āNew Backupā. The backup file is written into the backup folder, which is configured in the Admin -> Parameters section. By default, it is set to /web/projop/filestorage/backup/.
In the same page you can:
It is no problem to execute the PostgreSQL backup during the execution of ]project-open[, you don't need to stop the server. However, depending on system resources available, the backup will slow down the system slightly, so please choose some calm moments during the day.
You can also manually create a backup from the Linux/CygWin command line:
su - projop pg_dump --no-owner --clean --disable-dollar-quoting --format=p --file=/web/projop/filestorage/backup/pg_dump.[SERVER_NAME].projop.[YYYYMMMDD].[hhmmss].sql
We recommend that you use the name "pg_dump" for the backup dumps, and use our standard naming format. This format is used in all ]project-open[ installations and helps to limit errors when operating with database dumps from multiple servers.
In Linux configure a "Crontab" to execute the periodic backup:
# Backup PostgreSQL "projop" database every night 29 3 * * * /usr/bin/perl /root/bin/export-dbsThe export-dbs script creates a backup of all PostgreSQL databases into a backup directory.
āVacuumingā is the PostgreSQL name for performing database maintenance. Periodic maintenance is important for the overall performance of PostgreSQL, which can degrade considerably otherwise. The default ]project-open[ Windows installation does not include a periodic scheduling of the āvacuumā command. You can either:
On Linux systems configure the "Crontabs" daemon to execute the periodic maintenance.
# Full PostgreSQL vacuum every night 20 3 * * 0 su - postgres -c "/usr/bin/vacuumdb -a -f" >> /var/log/pg_vacuumdb.log 2>&1
su - projop psql āf pg_dump.xxxx.sql
Please note that this command will only succeed if:
show timezone
su - projop killall -9 nsd; dropdb projopPlease note the "killall -9 nsd". This command kills the AOLserver, so that PostgreSQL can drop the database. Otherwise PostgreSQL will complain that: āERROR: database āprojopā is being accessed by other usersā. In some cases (very fast systems) it is possible that you canāt drop the database this way. In that case please insert the following command as the first line of /web/projop/etc/config.tcl: # Wait 5 seconds for PostgreSQL to come up... exec sleep 5
su - projop createdb projop createlang plpgsql projop
su - projop psql āf pg_dump.xxxx.sql 2>&1 > import.log less import.log
Please note the āless import.logā. Please analyze the import.log file for errors:
su - projop cd ~/log rm * (delete all old log files) killall -9 nsd (restart AOLserver) less error.log (check the error log)Please note the āless error.logā command: Use this to search for āERROR:ā in the errror.log file.
System recovery is the process of recovering a ]project-open[ system after system crash or another incident.
The following Gantt chart gives you an overview over the procedure. The recovery of a system should be possible within 90 minutes if backups have been made correctly and if there is spare server hardware available.
# #!/bin/bash # # psql # # set -e # set -u cmd /c '%SystemRoot%\\system32\\WindowsPowerShell\\v1.0\\powershell.exe' -Command "spsv AOLserver-projop" rm -f /cygdrive/c/project-open/servers/projop/log/error.log dropdb -U postgres projop createdb -U postgres -O postgres -E utf8 projop cd /cygdrive/c/project-open/servers/projop/filestorage/backup/ psql -d projop -U postgres -f pg_dump.projop.20151204.001241.sql cmd /c '%SystemRoot%\\system32\\WindowsPowerShell\\v1.0\\powershell.exe' -Command "sasv AOLserver-projop"
# ####################### # IMPORTANT !!! # Goto cygwin shortcut properties and check: "Always run as Admin" # ------------------------ # Configure .bash_profile # Set POSTGRES PATH's export POSTGRES_HOME="/cygdrive/[DRIVE_LETTER]/project-open/pgsql/" export POSTGRES_LIB="/cygdrive/[DRIVE_LETTER]/project-open/pgsql/lib" export POSTGRES_INCLUDE="/cygdrive/[DRIVE_LETTER]/project-open/pgsql/include" export CVSROOT=":pserver:cvs@cvs.project-open.net:/home/cvsroot" export CVSREAD="yes" export CVS_RSH="ssh" # If problems w/ UNVALID ENV Variables: export CVS_PASSFILE="[DRIVE_LETTER]:/cygwin64/home/[USERNAME]/.cvspass" export PATH=$PATH:~/ alias "l=ls -als"
Following links to earlier versions of the Operations & Maintenance Guides
Calle Aprestadora 19, 12o-2a
08902 Hospitalet de Llobregat (Barcelona)
Spain
Tel Europe: +34 609 953 751
Tel US: +1 415 200 2465
Mail: info@project-open.com