(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.)
Each time one of the PIKT binaries (piktc, piktc_svc, pikt, piktd, or pikts) starts up, it looks for the PIKT configuration file, PIKT.conf, in =piktdir/etc. If it fails to find =piktdir/etc/PIKT.conf, it looks for /etc/PIKT.conf, then /etc/pikt/PIKT.conf, then /usr/local/etc/PIKT.conf, and finally /usr/local/etc/pikt/PIKT.conf. If it doesn't find PIKT.conf in any of those places, the program will abort.
Here is the format for the PIKT.conf file:
uid <uid> [0, or use any random integer] [gid <uid>] [0, or use any random integer] master <domainname> [fully-qualified domain name of master control machine, e.g., "vienna.uppity.edu"] domain <domain> [domain of master control machine, e.g., "uppity.edu"] access <local|global> [authenticate_by_master <yes|YES|on|ON|true|TRUE| no|NO|off|OFF|false|FALSE>] [defaults to 'yes'] [master_address <ipaddr>] [the ip address of the master control machine] [authenticate_by_master_address <yes|YES|on|ON|true|TRUE| no|NO|off|OFF|false|FALSE>] [defaults to 'no'] [master_ethernet_address <ethernet_addr>] [the ethernet address of the master control machine] [authenticate_by_master_ethernet_address <yes|YES|on|ON|true|TRUE| no|NO|off|OFF|false|FALSE>] [defaults to 'no'] [auth_encryption_type <0|1>] [0 is none (default), 1 is blowfish] [data_encryption_type <0|1>] [0 is none (default), 1 is blowfish] [private_key <key>] [private symmetric encryption key e.g., "what's up, doc?"; also: pvtkey] [pikttest_substitution <text>] [text substitution e.g., 'Test'; defaults to 'test'] [homdir <home directory>] [bindir <bin directory>] [etcdir <etc directory>] [lokdir <lock file directory>] [libdir <lib directory>] [vardir <var directory>] [altdir <alerts directory>] [prgdir <programs directory>] [objdir <objects directory>] [cfgdir <configs directory>] [hstdir <histories directory>] [logdir <log directory>] [arpcmd <arp command path>] [catcmd <cat command path>] [cksumcmd <cksum command path>] [cpcmd <cp command path>] [diffcmd <diff command path>] [echocmd <echo command path>] [egrepcmd <egrep command path>] [filecmd <file command path>] [nicecmd <nice command path>] [pscmd <ps command path>] [rmcmd <rm command path>] [rpcinfocmd <rpcinfo command path>] [scpcmd <scp command path>] [sumcmd <sum command path>] [tailcmd <tail command path>] [trcmd <tr command path>] [call_back <yes|YES|on|ON|true|TRUE|no|NO| off|OFF|false|FALSE>] [call_back defaults to 'yes'] [<service> <yes|YES|on|ON|true|TRUE|no|NO| off|OFF|false|FALSE>] ... [all services default to 'yes'] [tcp_only <yes|YES|on|ON|true|TRUE|no|NO| off|OFF|false|FALSE>] [tcp_only defaults to 'no'] [restart_piktc_svc_wait <seconds>] [number of seconds piktc will wait before verifying actual piktc_svc restart; the default is 5] [rpc_timeout <seconds>] [number of seconds piktc will wait for reply on a piktc -x (execute) request before timing out if no reply from the client; the default is 60] [rpc_retry_timeout <seconds>] [number of seconds piktc will wait for reply on a piktc -x (execute) request before retrying the request if no reply from the client; the default is 120, which turns off retry, in effect] [rpcinfo_retries <# retries>] [the number of times piktc retries establishing contact with a remote piktc_svc; the default is 1 retry, i.e., two attempts maximum] [execcmdout_limit <# chars>] [number of characters returned by a 'piktc -x +C' command; the default is 1000000 characters per client] [fork_delay <seconds>] [the number of seconds a parent process will delay after forking a child process; the default is 1] [verbose_log <yes|YES|on|ON|true|TRUE|no|NO| off|OFF|false|FALSE>] [verbose_log defaults to 'no'] [auto_syslog <yes|YES|on|ON|true|TRUE|no|NO| off|OFF|false|FALSE>] [auto_syslog defaults to 'no'] [syslog_facility [0-7]] [correspond to local0 through local7; default is 0 for local0] [sort_messages <yes|YES|on|ON|true|TRUE|no|NO| off|OFF|false|FALSE>] [sort_messages defaults to 'yes'] [debug <yes|YES|on|ON|true|TRUE|no|NO| off|OFF|false|FALSE>] [debug defaults to 'no']The four parameters--uid, master, domain & access--are all required. All other PIKT.conf parameters are optional.
The uid & gid have no role outside of master-slave authentication. We suggest that you set the PIKT.conf uid, and optionally the gid, to some arbitrary, random, and secret integer(s), thereby achieving a measure of "security through obscurity".
For example, in all systems' PIKT.conf, you could set
uid 491158200 gid 283617116and both the master and slave(s) will compare these numbers when authenticating. (That is, if the slave's uid and gid don't match the calling master's uid and gid, the service request is denied.)
By default, piktc_svc authenticates client requests by master name. By adding 'authenticate_by_master_address yes' and 'master_address <ipaddr>', you tell piktc_svc to check the IP address of the requesting client (the master system) before acceding to the request. The default is no authentication by master address. One or both of authenticate_by_master and authenticate_by_master_address can be 'yes', but both cannot be 'no'. These authentication parameters provide another security option as well as another thing to tweak in troublesome authentication situations (involving DNS and/or NIS problems).
If you add the following optional settings to PIKT.conf
master_ethernet_address 11:22:33:44:55:66 authenticate_by_master_ethernet_address TRUEthe PIKT slave will do an 'arp <piktmaster>' lookup of the piktmaster's MAC/ethernet address. Unless the returned address matches the address set in PIKT.conf, the service request is denied.
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 <piktmaster> <piktmaster's ethernet address>in the appropriate system startup file.
(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 FALSEor leave that out of their PIKT.conf files entirely. (The setting defaults to 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 #endifwhere 'local' is a hostgroup defined in your systems.cfg. You could set these systems by hand, but a better way would be to do it dynamically like this
local members #verbatim <systems/local_systems.cfg> [/pikt/bin/piktc -xI +C "/sbin/ifconfig -a | /usr/bin/grep 121.212.123 >/dev/null && /bin/hostname" -H down 2>/dev/null]if, for example, 121.212.123 identifies your piktmaster's subnet.
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)this will activate the authentication sequence described in piktc_svc, also in Security Considerations.
(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)this will activate encryption. (0 signifies the default, no encryption.)
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 thisisatestor this way
private_key "this is a test"that is, as a sequence of characters, none of which may be space or tab, or as a (double) quoted string, which may include spaces and/or tabs.
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., <path>/bin/pikt, <path> 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 <path>.) 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 (<path>, aka '=piktdir'), the PIKT binary expects to find certain essential directories in the following default locations
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_serviceThe 'tcp_only' parameter has many of the piktc server calls switch from their default UDP transport to a (possibly) more secure and more reliable TCP transport. This setting might also help solve some possible firewalling difficulties. Paradoxically, it seems to speed up certain forms of piktc-to-piktc_svc communications. Try setting tcp_only to TRUE if you are experiencing timeouts when attempting to connect to slave systems over slow or troublesome network connections.
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, <alert>.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|