Tengo un script para automatizar el arranque de unos cuantos servidores en el terminal. Son procesos de servidores del software que estoy desarrollando. Pueden ser recompilados y cambiados varias veces al día. Los binarios pueden vivir en diferentes lugares (copias de trabajo).
Mi script utiliza
set sudo to do shell script "sudo -v "
para pedir la contraseña de Root una vez, luego crea una nueva ventana de terminal iterm2 (y algunas pestañas) e intenta iniciar los servidores con sudo:
#!/usr/bin/osascript
on run args
set sudo to do shell script "sudo -v " -- to ask for password once only
tell application "iTerm"
create window with default profile
tell current window
tell current session
write text "sudo /some/server"
end tell
-- more tabs and more sudos go here
end tell
end tell
end run
Todo funcionaba bien en El Capitán, pero no en High Sierra.
Si el sudo
no se almacena en caché, el sudo -v
me pide mi contraseña y luego procede --- como se esperaba. Si ejecutara sudo
antes y la contraseña se almacena en caché, el sudo -v
no pide una contraseña, de nuevo, como se esperaba. Pero en ambos casos cada uno de los siguientes sudo
s en la nueva ventana sí me pide la contraseña, lo que hace que todo sea un inconveniente.
Cuando añado with administrator privileges
a la inicial sudo
me pide la contraseña en un cuadro de diálogo emergente, pero lo siguiente sudo
llamadas con write text
sigue pidiendo la contraseña en el shell. (Yo uso write text
y el terminal para vigilar las salidas de estos servidores).
Puedo ejecutar los comandos normales de sudo sin problemas y sí guarda la contraseña en la memoria.
¿Cómo puedo utilizar sudo
en Applescript en una nueva ventana de iTerm2 y que pida la contraseña sólo una vez?
EDITAR : Parece que esto no está relacionado con Applescript sino con iterm y High Sierra. Cuando abro una ventana de terminal con 2 pestañas, necesito introducir mi contraseña en ambas cuando ejecuto, por ejemplo, sudo ls
. Después de eso, ambas pestañas tienen la contraseña de sudo en la caché, pero ejecutar sudo en una pestaña no hace que la otra pestaña utilice la contraseña de sudo en la caché.
Así que la verdadera pregunta es probablemente: ¿cómo consigo que iTerm2 guarde en caché la contraseña de sudo y la comparta entre las pestañas y Windows?
1 votos
¿Ha pensado en configurar estos ejecutables para que se ejecuten como Root sin contraseña, en la carpeta
sudoers
¿Fichero? Consulte la página del manual desudoers
.0 votos
Set thePassword to "Password" as string do shell script <<TuComando>> ¬ password thePassword with administrator privileges
2 votos
@Gio Valerio, Personalmente yo configuraría los ejecutables para que se ejecuten como Root sin contraseña, en el archivo
sudoers
antes de utilizarpassword
conadministrator privileges
como el contraseña se guarda en texto sin formato dentro del archivo AppleScript.0 votos
Su terminología aquí es problemática.
sudo
no se lanza en AppleScript.sudo
se llama desde un intérprete de comandos no interactivo y sin inicio de sesión llamado por AppleScript. Cuando dice "iniciar algunos servidores", ¿puede explicar lo que quiere decir? ¿Estás iniciando un servicio (como Apache) o estás iniciando una máquina virtual (como VirtualBox)? Además, ¿quieres que esto ocurra cuando la máquina se inicia automáticamente o sólo cuando llamas manualmente al script?0 votos
No estoy seguro de lo que sucede con el texto en el applescript cuando se hace una aplicación de ellos, sin embargo la idea era probar que funcionaba. Después se puede dejar que el sistema (o el programa) pida la contraseña
1 votos
@Allan, creo que aunque interesante, sin embargo las preguntas que has hecho no abordan realmente la cuestión, que es que el OP tiene un script que funciona como se pretendía y quería en OS X 10.11 pero no en MacOS 10.13. Habiendo ejecutado el script en cada versión del SO, veo exactamente de lo que se está hablando. En OS X 10.11 si ejecuto
sudo <script_name>, I'm prompted for my password and then the script runs all of the
escribir texto "sudo /some/servidor"` comandos sin pedir de nuevo una contraseña. En MacOS 10.13, todos los comandoswrite text "sudo /some/server"
comandos espera a que vuelva a introducir la contraseña.0 votos
@Allan, Así que algo ha cambiado para romper lo que funciona en una versión anterior del sistema operativo. BTW realmente no veo nada malo con la terminología utilizada en el OP.
0 votos
Robert, puedo reproducir tu problema pero de momento no he investigado cuál es la causa. Por eso comenté antes, "¿Has considerado configurar estos ejecutables para que se ejecuten como Root sin contraseña, en la carpeta
sudoers
archivo?"0 votos
@user3439894 - Si corriera
sudo
antes y la contraseña se almacena en caché, elsudo -v
no pide contraseña, de nuevo, como era de esperar. Esto está directamente relacionado con el tipo de caparazón en el que se encuentra;sudo
no almacenará credenciales en caché en shells separados.1 votos
@Allan, has dicho "
sudo
no almacenará en caché las credenciales en shells separados" y eso no es totalmente cierto, ¡ejemplo! Puedo reproducir el problema del usuario. En OS X 10.8.6 y OS X 10.11.6 su script funciona como quería y pretendía sin embargo, no funciona en MacOS 10.13.1 como en OS X 10.8.6 y OS X 10.11.6. Por lo tanto, algo cambió entre OS X 10.11.6 y MacOS 10.13.1 bajo el que hice la prueba. Así que mientras "sudo
no almacenará en caché las credenciales en shells separados" es verdadero en MacOS 10.13.1 no es cierto en OS X 10.8.6 y OS X 10.11.6 según lo probado. Admito que no pensé que funcionaría, ¡pero lo hizo!0 votos
@user3439894 sudoers funciona bien, estoy feliz de aceptar que si desea publicar esto como una respuesta