Difference between revisions of "Wikid.pl"
m (→Account propagation) |
m (→Account propagation) |
||
| Line 8: | Line 8: | ||
The ''rpcSendAction'' function starts a new "RpcSendAction" job in the persistent work hash so that the attempt to send the message can keep retrying periodically until successful in the case of outages. The job consists of two functions, ''initRpcSendAction'' and ''mainRpcSendAction'', the first to establish the recipient and encrypt the action and its arguments using the ''$::netpass'' shared secret, and then the second function to attempt to connect and send the action and keep retrying periodically if it should fail to connect. | The ''rpcSendAction'' function starts a new "RpcSendAction" job in the persistent work hash so that the attempt to send the message can keep retrying periodically until successful in the case of outages. The job consists of two functions, ''initRpcSendAction'' and ''mainRpcSendAction'', the first to establish the recipient and encrypt the action and its arguments using the ''$::netpass'' shared secret, and then the second function to attempt to connect and send the action and keep retrying periodically if it should fail to connect. | ||
| − | The ''mainRpcSendAction'' function uses ''Net::Expect'' to connect to the remote peer using SSH and login with its own ''$::wikiuser'' and ''$::wikipass'' since that's guaranteed to have a corresponding unix account on all peers (but must be included in the ''AllowUsers'' clause). After it's shelled in it then executes the RPC by running the ''wikid.pl --rpc <encrypted-data>'' from the shell. | + | The ''mainRpcSendAction'' function uses ''Net::Expect'' to connect to the remote peer using SSH and login with its own ''$::wikiuser'' and ''$::wikipass'' since that's guaranteed to have a corresponding unix account on all peers (but must be included in the ''AllowUsers'' clause of ''sshd_config''). After it's shelled in it then executes the RPC by running the ''wikid.pl --rpc <encrypted-data>'' from the shell. |
When ''wikid.pl'' is run with the ''--rpc'' option, it simply formats the data into an event called ''RpcDoAction'' which is sent into the wiki daemon through its proper port as if it were a normal MediaWiki event coming through the ''EventPipe'', which results in the ''onRpcDoAction'' function being called. | When ''wikid.pl'' is run with the ''--rpc'' option, it simply formats the data into an event called ''RpcDoAction'' which is sent into the wiki daemon through its proper port as if it were a normal MediaWiki event coming through the ''EventPipe'', which results in the ''onRpcDoAction'' function being called. | ||
Unlike other wikid even handler functions, the ''$::data'' available to the ''onRpcDoAction'' handler is encrypted and so first needs to be converted back to an ''@args'' array (by base64 decoding, then decrypting with the shared ''$::netpass'' secret, then deserialising back into an array). If the action exists, then it is called along with the original arguments, otherwise an error is logged. If the action was broadcasted (having an empty "to" argument), then the same action and args will be sent to the next peer by calling ''rpcSendAction'' again at this point. | Unlike other wikid even handler functions, the ''$::data'' available to the ''onRpcDoAction'' handler is encrypted and so first needs to be converted back to an ''@args'' array (by base64 decoding, then decrypting with the shared ''$::netpass'' secret, then deserialising back into an array). If the action exists, then it is called along with the original arguments, otherwise an error is logged. If the action was broadcasted (having an empty "to" argument), then the same action and args will be sent to the next peer by calling ''rpcSendAction'' again at this point. | ||
Revision as of 11:02, 28 December 2009
|
Account propagation
When an account is created or updated in a wiki daemon's local wiki, the wiki will execute a PrefsPasswordAudit hook or a AddNewAccount hook which will then pass down the EventPipe into the wiki daemon and execute the onPrefsPasswordAudit or onAddNewAccount function, which then call doUpdateAccount with the appropriate arguments extracted from $::data.
In addition to calling doUpdateAccount which updates and synchronises the local unix and samba accounts, it also calls rpcBroadcastAction so that the same update occurs on all peers (starting with $::peer). The rpcBroadcastAction function actually just calls rpcSendAction with an empty "To" parameter to indicate a broadcast message.
The rpcSendAction function starts a new "RpcSendAction" job in the persistent work hash so that the attempt to send the message can keep retrying periodically until successful in the case of outages. The job consists of two functions, initRpcSendAction and mainRpcSendAction, the first to establish the recipient and encrypt the action and its arguments using the $::netpass shared secret, and then the second function to attempt to connect and send the action and keep retrying periodically if it should fail to connect.
The mainRpcSendAction function uses Net::Expect to connect to the remote peer using SSH and login with its own $::wikiuser and $::wikipass since that's guaranteed to have a corresponding unix account on all peers (but must be included in the AllowUsers clause of sshd_config). After it's shelled in it then executes the RPC by running the wikid.pl --rpc <encrypted-data> from the shell.
When wikid.pl is run with the --rpc option, it simply formats the data into an event called RpcDoAction which is sent into the wiki daemon through its proper port as if it were a normal MediaWiki event coming through the EventPipe, which results in the onRpcDoAction function being called.
Unlike other wikid even handler functions, the $::data available to the onRpcDoAction handler is encrypted and so first needs to be converted back to an @args array (by base64 decoding, then decrypting with the shared $::netpass secret, then deserialising back into an array). If the action exists, then it is called along with the original arguments, otherwise an error is logged. If the action was broadcasted (having an empty "to" argument), then the same action and args will be sent to the next peer by calling rpcSendAction again at this point.
