PIKT.conf

We make the recommendation, also, that you hard-code the piktmaster's MAC/ethernet address on each slave, either by registering this in /etc/ethers or by running the command

arp -s  

(If you register the piktmaster's ethernet address in /etc/ethers, consider managing this file in files.cfg.)

These steps will only bolster security for slaves sharing the same network segment as the piktmaster.  (For slaves on a different network segment, they will not know the piktmaster's MAC address, of course.  Issuing the above arp command on such systems will yield the results "no entry", "unavailable", or some equivalent.)  For slave systems on separate network segments, you must be sure to set

authenticate_by_master_ethernet_address         FALSE

If you manage your site's PIKT.conf from within files.cfg, you could do something like this:

#if local
        master_ethernet_address                         11:22:33:44:55:66
        authenticate_by_master_ethernet_address         TRUE
#else
        authenticate_by_master_ethernet_address         FALSE
#endif

local
        members
#verbatim  [/pikt/bin/piktc -xI +C
          "/sbin/ifconfig -a | /usr/bin/grep 121.212.123 >/dev/null &&
          /bin/hostname" -H down 2>/dev/null]

Different network topologies or arrangements would require different approaches.  How you handle this is your call.

For greater security, consider managing PIKT slaves from piktmaster machines on the same network segment only.  (It would be possible to have an uber-piktmaster push .cfg files to lower ranking piktmaster machines, one for each separate network segment.  That's a topic too advanced for the current discussion, however.)

Note that ARP authentication will not defeat a very skilled, experienced cracker.  It does provide an extra thin layer of security (and complexity), however, and may be worthwhile using in many situations.

By default, PIKT's key-keyenc-keysum authentication scheme is turned off.  However, if you add to PIKT.conf

auth_encryption_type    1    // 1 is blowfish,
                             // 0 is no encryption (default)

(The .rhosts-like authentication is always done.  callback is done unless you have set the call_back parameter to NO on the slaves.)

By default, data transfers between piktc and piktc_svc are not encrypted.  However, if you add to PIKT.conf

data_encryption_type    1    // 1 is blowfish,
                             // 0 is no encryption (default)

Encrypted data transfers include file installs (piktc -i), file fetches (piktc -f), and command executions (piktc -x).  The symmetric key employed for this encryption/decryption is the "session key" generated whenever piktc requests a service from piktc_svc.

If you set data_encryption_type to 1 (non-zero), you should also set auth_encryption_type to 1 (non-zero).  It makes little sense to set data_encryption_type to 1 but auth_encryption_type to 0.  You may set both to 0 if you want to skip encryption altogether (or when encountering difficulties, for example, when intermixing 64-bit & 32-bit systems).

For now, Blowfish is used both for encrypting/decrypting the authentication/session key as well as for encrypting/decrypting data transfers.  (We intend to make additional ciphers available in the future.)

By default, the private symmetric encryption key, pvtkey, is set to PVTKEY, defined by default in src/config.h as "CHANGE_ME".  You can override this either by editing src/config.h before doing the 'make' or by specifying '--with-private-key=FOO' when doing 'configure'.  PVTKEY is compiled into the binaries.

You can override PVTKEY in one of two ways:

• By specifying a private_key (or pvtkey) string in PIKT.conf.
• Or by specifying a key string in a PIKT etcdir/private_key file.

In PIKT.conf, you can set private_key (aka pvtkey) this way

private_key     thisisatest

private_key     "this is a test"

Your private_key (or pvtkey, or PVTKEY) must not exceed 56 characters in length.  (This is a Blowfish limitation.)

In order for a master piktc (and piktc_svc, when doing callback) to coordinate properly with a slave piktc_svc, all private_key (or pvtkey or PVTKEY) settings must be in agreement, as must auth_encryption_type and data_encryption_type.

It is vitally important to keep secret these and other settings in PIKT.conf (also etcdir/private_key, if you prefer that option)!  You should ensure 640 or perhaps 600 or 400 permissions for PIKT.conf (and etcdir/private_key), and secure the permissions on the etcdir directory (where PIKT.conf resides) and all of its parent directories as well.

When you need to update your PIKT.conf files with a revised private_key (or if you store the key in a stand-alone etcdir/private_key file), use scp or some other secure method for distributing those files.  Once you have the private_key established and PIKT encryption activated everywhere, you may of course manage secure installation of your PIKT.conf and/or etcdir/private_key like you would any other system file by way of, e.g., 'piktc -i +F PIKT.conf' or 'piktc -i +F private_key'.  Note that the new private_key won't take effect until you restart the piktc_svc daemons, either manually or via 'piktc -R'.

'piktc -T' set the sets the =pikttest built-in macro to 'test' by default.  You may use the pikttest_substitution parameter to specify a different substitution string, for example 'Test'.

If a PIKT binary is invoked as, e.g., /bin/pikt, is assumed to be the PIKT home directory by default.  (If the binary were invoked as simply, e.g., 'pikt', then the program searches through the PATH environment variable to determine .)  You can override this home directory default location by setting homdir to something else (e.g., '/usr/lib/pikt').

Having determined the PIKT home directory (, aka '=piktdir'), the PIKT binary expects to find certain essential directories in the following default locations

• /bin
• /etc
• /lib
• /lib/alerts
• /lib/programs
• /lib/objects
• /lib/configs
• /var
• /var/histories
• /var/log

When the PIKT binaries are compiled, several UNIX command paths are hard-coded in.  This would normally make it difficult to impossible to take binaries compiled on one system and use them on another with different command paths.  (It is of course impossible to take binaries compiled on one OS and use them on another.)  You may use the arpcmd, cksumcmd, ..., trcmd settings to override the hard-coded command paths as a workaround to this problem.

If call_back is set to 'no', then service-to-client, pikt_svc-to-piktc_svc callback is disabled.  For greater security, 'call_back yes' is the default.  If callback breaks under unusual circumstances, consider setting call_back to 'no'.

(callback is not currently supported on AIX, Digital UNIX, HP-UX, IRIX, or SCO systems.  If your master system is an AIX, Digital UNIX, HP-UX, IRIX, or SCO system, and if you have slave systems other than those types, then you will have to set call_back to 'no' on those slaves.  The call_back parameter is ignored on AIX, Digital UNIX, HP-UX, IRIX, and SCO OpenServer.)

The available services are:

    all_services                  ['yes' is the default; applies to all
                                   services listed below]

    kill_service                  [applies to both piktd & piktc_svc]
    kill_piktd_service
    kill_piktc_svc_service

    restart_service               [applies to both piktd & piktc_svc]
    restart_piktd_service
    restart_piktc_svc_service

    execute_service
    execute_commands_service      [needed for fetch services]
    execute_alerts_service        [or: execute_scripts_service]

    disable_alerts_service
    enable_alerts_service
    show_alerts_status_service

    install_service               [for alerts/scripts/programs/
                                       files/objects]
    install_alerts_service        [or: install_scripts_service]
    install_programs_service
    install_files_service
    install_objects_service

    fetch_service                 [for alerts/scripts/programs/
                                       files/objects]
    fetch_alerts_service          [or: fetch_scripts_service]
    fetch_programs_service
    fetch_files_service
    fetch_objects_service

    cksum_service                 [for alerts/scripts/programs/
                                       files/objects]
    cksum_alerts_service          [or: cksum_scripts_service]
    cksum_programs_service
    cksum_files_service
    cksum_objects_service

    delete_service                [for alerts/scripts/programs/
                                       files/objects]
    delete_alerts_service         [or: delete_scripts_service]
    delete_programs_service
    delete_files_service
    delete_objects_service

    list_service                  [for alerts/scripts/programs/
                                       files/objects]
    list_alerts_service           [or: list_scripts_service]
    list_programs_service
    list_files_service
    list_objects_service

The 'restart_piktc_svc_wait' parameter specifies how many seconds piktc, when doing a restart_piktc_svc (piktc -R), waits before rechecking the slave's piktc_svc pid in order to verify actual restart.  You might need to set this to a higher figure for particularly slow slave systems (thereby giving them extra time to spawn the substitute piktc_svc before the master's verification check).

The 'rpc_timeout' parameter tells piktc how long to wait (in seconds) for a reply after sending a -x, execute script, request to a client.  If you set this figure too low, piktc will erroneously infer failure if the executing script (or scripts) is (are) long and complicated.  If you set rpc_timeout too high, piktc may be kept waiting too long in cases of actual client-side piktc_svc failure (i.e., when piktc_svc is not running on the client).  By default, rpc_timeout is set to 60 seconds, 1 minute, which should give enough time for lengthy scripts to complete without blocking piktc too long in situations of actual timeout.  Adjust this parameter as necessary.

The 'rpc_retry_timeout' parameter tells piktc how long to wait (in seconds) for a reply after sending a -x, execute script, request before retrying the request when no response comes from the client.  Under normal circumstances, you should never set this below rpc_timeout, for then you risk executing the script(s) twice or more on the client.  By default, rpc_retry_timeout is set to twice the default rpc_timeout (120 and 60 seconds, respectively).  Under unusual circumstances, you might want to set rpc_retry_timeout below rpc_timeout.  Adjust as necessary.

The 'rpcinfo_retries' parameter tells piktc how many times to retry connecting to a remote piktc_svc.  The default is one retry--e.g., as many as two attempts as needed.  This parameter is useful when slow network connections cause piktc to infer that the remote piktc_svc is down when it is, in fact, up.  Set rpcinfo_retries to 2 or higher for really slow networks or slow remote systems.

rpc_timeout, rpc_retry_timeout, and rpcinfo_retries only need be set, if at all, in the master control machine's PIKT.conf file.

By default, a 'piktc -x +C' command will output to screen a maximum of 1,000,000 characters per client (i.e., per each host in the +H set).  You can set this to a lower or higher number using the execcmdout_limit parameter.

When a parent process forks a child process, it might need to wait for that child process to do something first.  The best way to handle this delay is for the parent to wait for some signal from the child.  At several places in the PIKT code, however, it is difficult or impossible to do it this way, so we just have the parent process wait an arbitrary time instead.  By default, these parent processes will wait 1 second.  If you experience odd program behaviors (e.g., unexplained program hangs), you might try upping fork_delay to 2 or more.  In some OSes, you might be able to reduce fork_delay to 0 and thereby achieve faster performance.

By default, verbose_log is set to 'no'.  You can activate a greater number of (less important) log messages by setting this to 'yes'.

By default, messages are sent to the syslog facility by means of 'output syslog' statements within Pikt scripts.  You can, additionally, send all program outputs, and all log messages (e.g., log messages ordinarily sent just to piktc_svc.log, .log, etc.), to syslog by setting the auto_syslog parameter to 'yes'.  This is especially useful if you send all such syslog messages to a central log host for further processing (for example, translating into some sort of graphical display), or just to centrally archive all PIKT-related messages.

If auto_syslog is set to 'yes', all PIKT messages are sent to the local0 facility by default.  You can override this default by setting the syslog_facility parameter to a number between 0 and 7 (corresponding to local0 through local7).

In alert messages, alarms are sorted by severity levels, from "emergency" (highest) to "debug" (lowest).  If for some reason you prefer that the alarm order you specify in the alerts.cfg listing determines the order of alarm output, you may override the default by means of the sort_messages setting (setting it to 'no').

If you set debug to 'yes' (the default is 'no'), all PIKT programs will run as if you had invoked them with the -G (debuG) command-line switch.

You may use ordinary PIKT-style // comments within PIKT.conf ('#' also serves as a commenting character in this file).

prev page

1st page

next page