0 votos

script para ejecutar Adobe Update Remote Manager como Launch Daemon en el arranque sin MDM

Escenario : Necesito averiguar cómo ejecutar el /usr/local/bin/RemoteUpdateManager en el ciclo de mantenimiento de DeepFreeze. Durante este ciclo de mantenimiento, los ordenadores se reiniciarán en la pantalla de inicio de sesión y entrarán en un modo de descongelación y bloqueo durante un periodo de tiempo. Como se mencionó no tenemos un MDM todavía, así que he creado un demonio de lanzamiento que a mi entender debe ejecutar el script en el arranque sin requerir ninguna entrada o para iniciar sesión.

Actualizar.sh

#!/bin/bash
rum=/usr/local/bin/RemoteUpdateManager

if [[ -f $rum ]]; then
echo "Starting Adobe RemoteUpdateManger..."
sudo $rum --action=list #Listing the updates for now, but will install later
else
echo "Adobe RemoteUpdateManager not found."
fi

Basado en la guía RUM de Adobe, enlace Tiene que usar sudo para RemoteUpdateManager

com.test.schedule.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>EnviromentVariables</key>
<dict>
    <key>PATH</key>
    <string>/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:</string>
</dict>
<key>Label</key>
<string>com.test.updateschedule</string>
<key>ProgramArguments</key>
<array>
    <string>sudo</string>
    <string>sh</string>
    <string>/Library/Scripts/Updates.sh</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>StandardErrorPath</key>
<string>/var/log/EsoUpdateError.log</string>
<key>StandardOutPath</key>
<string>/var/log/EsoUpdate.log</string>

Pasos dados

  1. Copie update.sh en /Library/Scripts/ y el .plist a /Library/LaunchDaemons/
  2. sudo chown root:wheel .sh
  3. sudo chown root:wheel .plist.
  4. sudo launchctl load -w /Library/LaunchDaemons/.plist
  5. En el momento en que cargo el .plist, crea dos registros en /var/log/ . El registro de standardoutpath lista todas las actualizaciones que es exactamente lo que quiero.

Edición

Después de reiniciar el ordenador para ver si los resultados se mantienen, observo que los resultados no se pueden reproducir. En su lugar recibo lo siguiente en el registro StandardErrorPath:

RemoteUpdateManager sale con código de retorno (1)

Basado en la guía RUM, el Código de Retorno (1) es: "Error genérico, por ejemplo un error interno. Por ejemplo, podría ser el caso de que la instalación de Adobe Application Manager esté dañada o la red no esté presente. En este caso, normalmente, el proceso de descarga o instalación de actualizaciones no puede iniciarse en absoluto".

Llegué a aplicar chmod 777 y chown Root:wheel tanto en el .sh como en el .plist, junto con `/usr/local/bin/RemoteUpdateManager'. Probé sin sudo en el .plist y en el .sh.

1voto

AzironaZack Puntos 1

Como el plist de launchd está en /Library/LaunchDaemons/ se va a ejecutar como Root. Dado esto, no necesitas llamar a sudo como primer argumento del programa, ni tampoco es necesario en el shell script. Además, es una buena práctica utilizar rutas completas en los argumentos del programa para /bin/sh en lugar de sh .

Sin embargo, todo esto es sólo una cuestión de orden. Lo que me parece interesante es que funciona cuando estás conectado como usuario pero no funciona cuando launchd lo ejecuta al cargar durante el reinicio. La sección de la página man de launchd.plist para RunAtLoad tiene esta pequeña advertencia:

Esta clave debe evitarse, ya que los lanzamientos de trabajos especulativos tienen un efecto adverso en los escenarios de arranque del sistema y de inicio de sesión del usuario.

Por esta razón, evito utilizar RunAtLoad true para las tareas launchd de nivel Root. Sospecho que lo que estás viendo es que el sistema no está preparado para ejecutar RemoteUpdateManager en el momento en que launchd carga su plist.

RunAtLoad es terriblemente Sin embargo, es muy útil, así que puede que tengas que seguir con él, pero yo jugaría con otros mecanismos para decirle a launchd cuándo ejecutar tu script. Podrías intentar usar StartInterval 60 o algo así para dar al sistema 60 segundos para girar completamente después de cargar el plist. Eso supone que su ventana de mantenimiento es de al menos 60 segundos más el tiempo que necesite su script. Una alternativa podría ser potencialmente usar StartCalendarInterval pero hay que estar muy seguro de que la ventana de mantenimiento está rígidamente definida en el tiempo y no es cancelable por los usuarios.

También puede mantener RunAtLoad y utilizar KeepAlive con SuccessfulExit true para que launchd siga intentando ejecutar su script hasta que salga con éxito. No es una solución elegante pero puede funcionar. Si hace esto, asegúrese de configurar su ThrottleInterval a algo razonable o de lo contrario launchd se quejará sin piedad si la tarea falla permanentemente.

La última cosa a tener en cuenta es que su plist va a hacer que su shell script se ejecute en cada reinicio. Deberías incorporar algún mecanismo en tu shell script para detectar si estás en un periodo de mantenimiento y exit 0 si no.

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X