OpenCRVS
v1.4
v1.4
  • 👋Welcome!
  • CRVS Systems
    • Understanding CRVS
    • Effective digital CRVS systems
    • OpenCRVS within a government systems architecture
    • OpenCRVS Value Proposition
  • Product Specifications
    • Functional Architecture
    • Workflow management
    • Status Flow Diagram
    • Users
      • Examples
    • Core functions
      • 1. Notify event
      • 2. Declare event
      • 3. Validate event
      • 4. Register event
      • 5. Print certificate
      • 6. Issue certificate
      • 7. Search for a record
      • 8. View record
      • 9. Correct record
      • 10. Verify record
      • 11. Archive record
      • 12. Vital statistics export
    • Support functions
      • 13. Login
      • 14. Audit
      • 15. Deduplication
      • 16. Performance management
      • 17. Payment
      • 18. Learning
      • 19. User support
      • 20. User onboarding
    • Admin functions
      • 21. User management
      • 22. Comms management
      • 23. Content management
      • 24. Config management
    • Data functions
      • 25. Legacy data import
      • 26. Legacy paper import
  • Technology
    • Architecture
      • Performance tests
    • Standards
      • FHIR Documents
        • Event Composition
        • Person
        • Registration Task
        • Event Observations
        • Locations
    • Security
    • Interoperability
      • Create a client
      • Authenticate a client
      • Event Notification clients
      • Record Search clients
      • Webhook clients
      • National ID client
      • FHIR Location REST API
      • Other ways to interoperate
  • Default configuration
    • Intro to Farajaland
    • Civil registration in Farajaland
    • OpenCRVS configuration in Farajaland
      • Application settings
      • User / role mapping
      • Declaration forms
      • Certificate templates
    • Business process flows in Farajaland
  • Setup
    • 1. Planning an OpenCRVS Implementation
    • 2. Establish project and team
    • 3. Gather requirements
      • 3.1 Mapping business processes
      • 3.2 Mapping offices and user types
      • 3.3 Define your application settings
      • 3.4 Designing event declaration forms
      • 3.5 Designing a certificate template
    • 4. Installation
      • 4.1 Set-up a local development environment
        • 4.1.1 Install the required dependencies
        • 4.1.2 Install OpenCRVS locally
        • 4.1.3 Starting and stopping OpenCRVS
        • 4.1.4 Log in to OpenCRVS locally
        • 4.1.5 Tooling
          • 4.1.5.1 WSL support
      • 4.2 Set-up your own, local, country configuration
        • 4.2.1 Fork your own country configuration repository
        • 4.2.2 Set up administrative address divisions
          • 4.2.2.1 Prepare source file for administrative structure
          • 4.2.2.2 Prepare source file for statistics
        • 4.2.3 Set up CR offices and Health facilities
          • 4.2.3.1 Prepare source file for CRVS Office facilities
          • 4.2.3.2 Prepare source file for health facilities
        • 4.2.4 Set up employees & roles for testing or production
          • 4.2.3.1 Prepare source file for employees
          • 4.2.3.2 Configure role titles
        • 4.2.5 Set up application settings
          • 4.2.5.1 Managing language content
            • 4.2.5.1.1 Informant and staff notifications
          • 4.2.5.2 Configuring Metabase Dashboards
        • 4.2.6 Configure certificate templates
        • 4.2.7 Configure declaration forms
          • 4.2.7.1 Configuring an event form
        • 4.2.8 Seeding & clearing your local databases
        • 4.2.9 Countryconfig API endpoints explained
      • 4.3 Set-up a server-hosted environment
        • 4.3.1 Verify servers & create a "provision" user
        • 4.3.2 HTTPS & Networking
        • 4.3.3 Create a Github environment
          • 4.3.3.1 Environment secrets and variables explained
        • 4.3.4 Provision environments
          • 4.3.4.1 Building, pushing & releasing your countryconfig code
        • 4.3.5 Deploy
    • 5. Functional configuration
      • 5.1 Configure application settings
      • 5.2 Configure registration periods and fees
      • 5.3 Managing system users
    • 6. Quality assurance testing
    • 7. Go-live
      • 7.1 Pre-Deployment Checklist
    • 8. Operational Support
    • 9. Monitoring
      • 9.1 Application logs
      • 9.2 Infrastructure health
      • 9.3 Routine monitoring checklist
      • 9.4 Setting up alerts
      • 9.5 Managing a Docker Swarm
  • General
    • Community
    • Contributing
    • Releases
      • v1.4.1: Release notes
      • v1.4.0 to v1.4.1 Migration notes
      • v1.4.0 Release notes
      • v1.3.* to v1.4.* Migration notes
      • v1.3.5: Release notes
      • v1.3.4: Release notes
      • v1.3.3: Release notes
      • v1.3.1: Release notes
      • v1.3.* to v1.3.* Migration notes
      • v1.3.0: Release notes
      • v1.2.* to v1.3.* Migration notes
        • v1.2 to v1.3: Form migration
      • v1.2.1: Release notes
      • Patch: Elasticsearch 7.10.2
      • v1.2.0: Release notes
      • v1.1.* to v1.2.* Migration notes
      • v.1.1.2: Release notes
      • v.1.1.1: Release notes
      • v1.1.0: Release notes
    • Interoperability roadmap
    • Product roadmap
Powered by GitBook
On this page
  • Documentation updates
  • Note
  • New features
  • Breaking changes
  1. General
  2. Releases

v1.4.0 Release notes

In OpenCRVS v1.4.0 we have entirely refactored infrastructure provisioning in opencrvs-countryconfig. There are no changes to opencrvs-core.

Previousv1.4.0 to v1.4.1 Migration notesNextv1.3.* to v1.4.* Migration notes

Last updated 1 year ago

Upgrading from v1.3.0 to v1.4.0 requires the upgrade to be followed precisely.

Documentation updates

The documentation section has been entirely re-written for the new infrastructure provisioning tasks. We recommend that you read it before continuing.

Note

In the next OpenCRVS release v1.5.0, there will be two significant changes:

  • The infrastructure directory and related pipelines will be moved to a new repository.

  • Both the new infrastructure repository and the OpenCRVS country resource package repositories will start following their own release cycles, mostly independent from the core's release cycle. From this release forward, both packages are released as "OpenCRVS minor compatible" releases, meaning that the OpenCRVS countryconfig 1.3.0- is compatible with OpenCRVS 1.3.0, 1.3.1, 1.3.2, etc. This allows for the release of new hotfix versions of the core without having to publish a new version of the infrastructure or countryconfig.

New features

🔒 Entirely reconfigured infrastructure and provisioning scripts for new servers. Each server is now SSH secured with Google Authenticator.

🔒 Backup server now automatically provisioned. Production environments automatically back up to backup server and they are automatically restored onto staging, thus reducing monitoring and maintenance tasks.

An example Wireguard VPN configuration is now supplied.

We now recommend creating a new Ubuntu user provision with passwordless sudo rights for all automated operations on the server, instead of using the root user. New users for different operations will be created in future releases.

All human users on all servers now have their own Linux users with mandatory 2-factor authentication.

OpenCRVS now has an interactive script environment:init for creating new Github environments and defining secrets. This script should also be run for existing environments to ensure all variables and secrets are defined, especially important when pulling the latest changes from the repository to your own country resource package.

The environment creator script also manages the known hosts file automatically.

🚰 New pipeline for automatic provisioning of Ubuntu servers (all environments).

🚰 New pipeline for resetting data from an environment (non-production environments).

🚰 New pipeline for resetting SSH 2FA for all environments.

🚰 Development deploy pipeline now includes a "debug" option for SSHing into the action runner (non-production environments).

A new "staging" environment has been introduced, acting as a production environment clone that resets its data nightly to match the production environment.

The deployment script can now verify if there are undefined environment variables referred to in your compose files. All secrets and variables defined in Github Environments are automatically passed down to the deployment script.

🔒 Backup archives are now secured with a passphrase.

HTTPS setup now offers three options: HTTP challenge, DNS challenge, and using a pre-issued certificate file.

There's now a generic purpose POST /email endpoint only available from the internal network. Elastalert2 is configured to use this endpoint instead of directly using SMTP details or the Sendgrid API key.

🔒 QA environment now hosts a Wireguard server and admin panel (wg-easy). After deploying, you can access the admin panel at vpn..

Allow configuring additional SSH parameters globally using SSH_ARGS Github variable.

Breaking changes

  • Added examples for configuring HTTP-01, DNS-01, and manual HTTPS certificates. By default, development and QA environments use HTTP-01, while others use DNS-01.

  • An automated script now generates all secrets & variables defined in Github Secrets and creates appropriate Github environments. They are now passed automatically to the deployment script.

  • The VPN_HOST_ADDRESS variable is now required for staging and production installations to ensure deployments are not publicly accessible.

  • Replica limits have been removed; any number can now be deployed.

  • Each environment now has a dedicated docker-compose--deploy.yml. Use environment:init to create a new environment and generate a corresponding file for customizable configurations.

  • 🔒 OpenHIM console is no longer exposed via HTTP.

  • Ansible playbooks are refactored into smaller task files.

  • Known hosts are now defined in the infrastructure/known-hosts file. You can clear the file and use bash infrastructure/environments/update-known-hosts.sh <domain> to add your own domains.

  • Ansible inventory files are now in .yml format. Please convert your old production.ini and similar files to this new format.

  • The authorized_keys file has been removed, and keys should now be defined in the inventory yaml files.

  • The DOCKER_PASSWORD secret has been replaced with DOCKER_TOKEN.

Migration Notes
3.3 Set-up a server hosted environment