Skip site navigation (1) Skip section navigation (2)

proposal: a validator for configuration files

From: Alexey Klyukin <alexk(at)commandprompt(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: proposal: a validator for configuration files
Date: 2011-03-30 15:40:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

I'd like to add an ability to validate the corectness of PostgreSQL
configuration files, i.e. postgresql.conf, pg_hba.conf, pg_ident.conf without
actually applying them. The idea is that it would be a command-line option to
postgres for a stand-alone case, or a user-callable function when postmaster
is running.

Per the former discussion of a validator for PostgreSQL configuration files
here's an implementation proposal. The development plan consists of 2 parts.
The first one is to add new code that would allow running the checks in both a
stand-alone process, when postmaster is not running, and as a function call
from a backend postgres process. Initially the code would simply loads
configuration files, without performing any of the validation checks. The
second part consists of adding specific checks.

I think most of the code related to this feature should be put into the
auxiliary process. The rationale is that we already have a stand-alone
CheckerProcess, which nowadays only parses postgresql.conf, runs BaseInit and
exists. We can easily load pg_hba.conf and pg_ident.conf and run all the
necessary checks there. Moreover, the same process can be used when checks are
launched from a built-in function. In that case, it would save the postgres
backend from reloading postgresql.conf, pg_hba.conf and pg_ident.conf
internally and restoring the previous configuration options when the function
exists. Below is a more detailed description of implementation steps:

1.1. Stand-alone process (postmaster is not running):

- Add a new option (--check-config) to main.c. Run AuxiliaryProcessMain with
  auxType= CheckerProcess if this option is specified.
- In CheckerModeMain load pg_hba.conf, pg_ident.conf

1.2. Built-in function, called from a backend process.
- Add a new built-in function
- Add LastCheckState shared flag to denote whether the check has been
  successful or failed
- Add a new PMSignalReason 
- From the function call SendPostmasterSignal with the reason added on the
  previous step.
- In the postmaster add a check for this reason in sigusr1_handler, spawning
  a checker process. Set LastCheckStatus to InProgress.
- Store current configuration options in AuxillaryProcessMain before reloading
  configuration files to avoid checking for options that haven't changed.
- In AuxillaryProcessMain, modify SelectConfigFiles invocation to call it
  if IsUnderPostmaster = true if auxType process type is CheckerProcess.
- In the CheckerModeMain, set LastCheckState to either success or failure at the
  end of all checks.
- The built-in function would wait until LastCheckState changes its value from
  InProgress to either Succcess or Failure, or until some predefined timeout
  expires, in which case it would emit an error.

2. Add following configuration checks:


Check that:
  1. postgres can bind to listen address:port
  2. unix_socket_directory has proper permissions (n/a on Windows).
  3. unix_socket_group group exists on a target system (n/a Windows).
  4. unix_socket_permissions are valid (write permission is not revoked from
        the owner, or a group, if group is different from the user).
  5. server.crt and server.key exist in the data directory if ssl is
        set to true (and server is compiled with openssl)
  6. krb_server_keyfile is readable by the server (if  set)
  7. server is not requesting more shared memory than it's available in the system.
  8. shared_preload_libraries and local_preload_libraries exist.
  9. synchronous_standby_names are not empty and max_wal_senders
        are > 0 if synchronous_replication = true
  10. all enable_*  query planner parameters are on.
  11. seq_page_cost <= random_page_cost, and cpu_ costs are lower than page_ costs.
  12. effective_cache_size is less than the amount of physical memory available.
  13. geqo is turned on
  14. default_statistics_target is >= 100
  15. logging collector is enabled if log destination is stderr
  16. log directory either exists and writable or that the parent
         directory allows creating subdris
  17. track counts is on if autovacuum is enabled
  18. stats_temp_directory is writeable
  19. default tablespace exists (if set)
  20. temp_tablespace exists (if set)
  21. statement_timeout is 0 (disabled)
  22. dynamic_library_path exists
  23. sql_inheritance is off
  24. zero_damaged_pages is off
Check that:
  1. the server is compiled with ssl if hostssl is specified
  2. ssl is not required if hostnossl is specified

- Add a Warning value to LastCheckState for cases when configuration
files were loaded successfully, but one or more validation checks have failed.

Note that these are basic checks don't require the checker process to have
access to the database, Also, with this implementation, a client won't receive
an exact error message in case validation is unsuccessful, however, it would
receive a status (success, failure, warnings), and an exact error message
would be available in the server's log. It's possible to address these
shortcomings in the future.

Ideas, suggestions are welcome.

Alexey Klyukin
The PostgreSQL Company - Command Prompt, Inc.


pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2011-03-30 15:43:53
Subject: Re: Process local hint bit cache
Previous:From: Dimitri FontaineDate: 2011-03-30 15:37:04
Subject: Re: Another swing at JSON

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group