<HTML><HEAD></HEAD>
<BODY dir=ltr>
<DIV dir=ltr>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: 'Calibri'; COLOR: #000000">
<DIV>Because I want to get to a place where running ansible and loading content 
can be managed through an admin gui, I have started thinking about a command 
server, a sort of callable job queue.</DIV>
<DIV> </DIV>
<DIV>I want to give certain admin users the ability to launch commands which run 
as root and may be long-running.  Such commands should survive a restart 
and it should be possible to monitor progress.</DIV>
<DIV> </DIV>
<DIV>I am leaning towards the following approach:</DIV>
<DIV> </DIV>
<DIV>1. A command server based on ZeroMQ implemented as a systemd service which 
is always running as root.</DIV>
<DIV>2. Input to the command server is through a unix domain socket which is 
owned by root and rw only for anyone in a group whose members are apache and 
probably xsce-admin.</DIV>
<DIV>3. The command server uses sqlite for persistent storage owned by root and 
rw by owner.  Probably the schema distinguishes between command requests 
and jobs.</DIV>
<DIV>4. A php or python script invoked by an ajax call from the admin gui 
invokes a command on the command server. The gui would be user/password 
protected.</DIV>
<DIV>5. The command server parses the request and checks if it has already been 
requested.</DIV>
<DIV>If the command is new:</DIV>
<DIV>6. The command server logs the command into persistent storage and 
immediately returns a response with probably OK or Error depending.</DIV>
<DIV>7. It translates it into a shell command based on internal logic.  It 
NEVER simply executes a command it gets from the gui.</DIV>
<DIV>8. The command server forks a child which runs the appropriate command in 
background, returns its pid, and terminates.  The pid is put in persistent 
storage.</DIV>
<DIV>If the command is a duplicate:</DIV>
<DIV>9. The command server verifies that the command is running and to the 
extent possible its percent of completion and returns status to the 
caller.</DIV>
<DIV>10. There would also be status commands to return a list of current jobs or 
status of an active job and perhaps jobs marked active that are not 
running.</DIV>
<DIV>11. If the command server crashes or the system is restarted, the command 
server attempts to restart active jobs.</DIV>
<DIV> </DIV>
<DIV>Possible commands are:</DIV>
<DIV> </DIV>
<DIV>rsync-iiab-content – copy various iiab files to their destination in 
/library.  The source is a parameter, but not the destination to keep from 
copying malware into /usr/bin, etc.  Some attempt would also be made to 
verify the source to prevent malicious content.</DIV>
<DIV>rsync-rachel-content – similar</DIV>
<DIV>rsynce-kiwix-content – the list could grow</DIV>
<DIV>runtag</DIV>
<DIV>runansible</DIV>
<DIV>reboot</DIV>
<DIV> </DIV>
<DIV 
style="FONT-SIZE: 12pt; FONT-FAMILY: 'Calibri'; COLOR: #000000">Tim</DIV></DIV></DIV></BODY></HTML>