piktc_svc

(NOTE: Some of the techniques shown or described on this page--marked in purple--require new features in the latest official PIKT 1.19.0 release (pikt-current.tar.gz) that are unavailable in any previous version.)

piktc_svc is the PIKT service daemon. Its job is to listen to requests from the piktc master control program and execute those service requests on client systems. Here are the piktc_svc command options:

Usage:  piktc_svc [-GhTVz]

        -G                      run in debug mode
        -h                      show program help
        -T                      run in test mode
        -V                      show version info
        -z                      run in 'make check' mode

The options operate much the same as for piktc.

The -G option turns on debugging. Debug messages are sent to the piktc_svc.log file.

The -h option shows program help (shown above).

The -T option runs piktc_svc in test mode. This has no special effect and is there to be consistent with the other PIKT binaries.

The -V option will output version information, e.g., "PIKT piktc_svc version 1.19.0".

The -z option runs piktc_svc in 'make check' mode. You ordinarily wouldn't do this outside the installation 'make check'.

piktc_svc is invoked manually, begins at system startup (in the system startup files), or starts using some other service daemon startup utility (See, for example, svcstart.pl in the sample programs.cfg.) piktc_svc does piktc's bidding, handling the actual file installs, alert enablements/disablements, daemon (re)starts, etc. on the client system. Under normal circumstances, while the system is up, piktc_svc never dies.

When piktc_svc launches, it creates a lock file in the =piktdir/etc directory, and removes that file upon completion. The lock file mechanism is to prevent concurrent piktc_svc program runs. In cases of abnormal piktc_svc termination, it will be necessary to manually remove the lock file.

piktc on the master control machine can send requests to piktc_svc on slaves either within the local domain or in different network domains, depending on how you have set up systems.cfg and installed PIKT. If you want to control machines beyond the local domain, you must set the access option in the =piktdir/etc/PIKT.conf file to "global".

PIKT master-slave, client-server communications rely on a four-tier security mechanism involving (1) host authentication, (2) secret key authentication, (3) service access rights, and (4) server-client callback.

When the master piktc wants a slave piktc_svc to do its bidding, the following sequence of events occurs:

The master piktc requests an authentication/session key (key) from the slave piktc_svc.
The slave piktc_svc generates the authentication/session key (key). It then computes the MD5 checksum of key (keysum). The slave piktc_svc then returns the encrypted key (keyenc) to the master piktc. The pvtkey (private_key set in PIKT.conf and elsewhere) is the symmetric key used for encrypting/decrypting the authentication/session key (keyenc).
The master piktc decrypts, using pvtkey, the encrypted key (keyenc), giving it the authentication/session key (key). It, too, computes the MD5 checksum of its copy of the key (keysum). It passes its key's checksum (keysum), along with the service request, back to the slave piktc_svc.
The slave piktc_svc does some .rhosts-like authentication checks. If everything passes, it proceeds to the next step, else denies the service.
If the master's sent key checksum (keysum) matches the slave's key checksum (keysum), the slave piktc_svc proceeds to the next step, else denies the service.
The slave piktc_svc checks to see if the requested service is authorized, and if so proceeds to the next step, else denies the service.
The slave piktc_svc does a PIKT-style server-client callback (described below).
If everything checks security-wise, the slave piktc_svc fulfills the master piktc's service request, else denies the service.

Diagrammatically, secret key authentication proceeds like this:

          MASTER                               SLAVE

          piktc                              piktc_svc

      (1) request key ----------------->
                                         (2) generate key
                                         (3) compute keysum
                                         (4) encrypt key
          <----------------------------- (5) return keyenc
      (6) decrypt keyenc
      (7) compute keysum
      (8) send request & keysum ------->
                                         (9) compare two keysums

PIKT callback works as follows: When you issue a piktc command, and if call_back is turned on in PIKT.conf,

The slave (remote) host and requested service are registered with the master (local) piktc_svc.
The master piktc sends the service request to the slave (remote) piktc_svc.
Upon receiving the service request, the slave piktc_svc does a callback back to the master piktc_svc, seeking to verify the request.
The master piktc_svc attempts to match the callbacking slave and service request with the locally registered host and service request. It returns the results of the attempted match to the slave piktc_svc.
If the slave piktc_svc receives report of a successful match, only then does the slave piktc_svc perform the requested service.
The slave piktc_svc returns the outcome of the service request to the requesting piktc.
The master piktc_svc deregisters the slave host and requested service.

Diagrammatically, callback proceeds this way:

          MASTER                               SLAVE

          piktc <--------------------------------+
            |         (2) send request           |
            |         (6) return result          |
            |                                    |
            |  (1) register slave & request      |
            |  (7) deregister slave & request    |
            V                                    V
          piktc_svc <-----------------------> piktc_svc
                      (3) callback                         
                      (4) match & reply   (5) perform service?

The host authentication is always performed. The secret key authentication is (effectively) done only if auth_encryption_type is set to 1 (some number other than 0, for now just 1) in PIKT.conf. Callback is only performed if the call_back parameter is set to ON in the slave PIKT.conf.

In PIKT.conf, if you set data_encryption_type to some number other than 0 (for now, just 1), this will encrypt some data transfers between piktc and piktc_svc. Encrypted data transfers include file installs (piktc -i), file fetches (piktc -f), and command executions (piktc -x). The symmetric encryption key employed for this data encryption/decryption is the "session key" described above.

There is a separate authentication/session key generated and exchanged for each and every service request. So, for example, if you install five files from master to slave, five different authentication/session keys are used.

The private_key doesn't vary unless you change it by, say, substituting a different private_key in PIKT.conf, then installing the revised PIKT.conf on all systems. If you store the private key in an etcdir/private_key file, you would revise and reinstall that file instead. Note that a revised private_key (and any other changed PIKT.conf parameters) won't take effect until you restart all affected piktc_svc, either manually or via 'piktc -R'.

See the PIKT.conf and keys.conf sections of this Reference manual for more information.

For more discussion of PIKT's security mechanisms, please refer to the Security Considerations section of this reference.

Every time piktc sends a service request to a client system, this is logged in the =piktdir/var/log/piktc.log file. Likewise, piktc_svc logs, to =piktdir/var/log/piktc_svc.log, every service request it receives. If enabled, callback traffic is logged on both master and slave.

If piktc_svc receives a request from an unauthorized account or system, it flags this as an "ERROR". You can use other log file monitoring Pikt scripts to alert you to this possible security violation. You can also have scripts to analyze and compare the piktc.log and various piktc_svc.log files to verify the validity of service requests.

Don't forget, too, that you can inspect the log files when and if master-slave, piktc-piktc_svc communications go wrong. When debugging master-slave breakdowns, you should run both piktc and piktc_svc in debug (-G) mode. Try, also, setting 'verbose_log' to 'yes' in PIKT.conf (see below).

1st page