Puedo crear y lanzar una aplicación como esta:

express -s -t ejs
npm install express
npm install ejs
node app.js

y funciona (en el puerto 3000). Pero cuando me vaya y cambiar el puerto 80, a continuación, ejecutar node app.js salidas de este:

node.js:198
throw e; //process.nextTick error, or 'error' event on first tick
          ^
TypeError: Cannot call method 'getsockname' of null
at HTTPServer.address (net.js:746:23)
at Object.<anonymous> (/var/www/thorous/app.js:35:67)
at Module._compile (module.js:432:26)
at Object..js (module.js:450:10)
at Module.load (module.js:351:31)
at Function._load (module.js:310:12)
at Array.<anonymous> (module.js:470:10)
at EventEmitter._tickCallback (node.js:190:26)

Esto también funciona en mi laptop, pero no en mi instancia de Amazon EC2, donde el puerto 80 está abierto.
Puede averiguar lo que está mal. Algún consejo?

  • Eso es un terrible mensaje de error.
InformationsquelleAutor Vitaly | 2011-10-28

4 Comentarios

  1. 64

    Es el punto de partida de su aplicación como root? Porque los menores números de puerto se requieren privilegios de root.
    Tal vez un sudo nodo app.js funciona?

    PERO, usted NO debe correr ningún node.js aplicación en el puerto 80 con privilegios de root!!! NUNCA!

    Mis sugerencias es ejecutar nginx en la frente como un proxy inverso a su node.js la aplicación se ejecuta en el puerto por ejemplo, 3000

    • Podría usted comentar por qué no ejecutar un node.js app como root en el puerto 80? Im curioso (un novato js dev).
    • Esto no se aplica a nodo único. No se recomienda ejecutar cualquier software de servidor como root. Si es necesario, porque desea utilizar un privilegiado puerto, el proceso pierde los privilegios y «hacia delante» todo el tráfico entrante en el puerto para el correspondiente proceso que se ejecuta en un menor provileged usuario. Esto es porque el programa no es perfecto. Cada software tiene bugs y tal vez los problemas de seguridad. Si un atacante puede utilizar tales errores e inyectar código este se ejecuta como el usuario que ejecuta este proceso. Así que si el proceso se ejecuta como root el atacante podría hacer nada en su máquina.
    • Ejecución de nginx como un proxy inverso es un poco excesivo en este caso. Yo sugiero utilizar iptables para el reenvío de puertos, a menos que haya nginx la funcionalidad que usted necesita en frente de el Expreso de la aplicación.
    • ¿Por qué tenemos que generalmente se ejecuta Apache en el puerto 80 si usted está diciendo que no debemos correr el Nodo no?
    • Porque, como cualquier otro proceso, apache necesita privilegios de root para poder escuchar en el privilegiado el puerto 80. PERO inmediatamente se crea «procesos de trabajo» y las gotas de sus privilegios a un menor de privilegio de usuario y de grupo y, a continuación, transfiere todas las solicitudes entrantes en el puerto para sus procesos de trabajo. Pero el nodo es un proceso único – que usted puede pensar en ello como un proceso de trabajo de apache. Si desea ejecutar el nodo en el 80 todo el proceso – cada instrucción – tendría que ejecutar como root. Así que es una especie de una configuración similar como nginx(80) –> nodo(3000)
    • Ah, eso tiene más sentido. Así que iba a tener Apache en un puerto, además de 80 a estar mejor en cualquier forma sobre la necesidad de que en los 80?
    • Apache gotas de sus privilegios, de sus «procesos de trabajo», etc. automáticamente a sí mismo. Así que no hay necesidad de tratar de ajustar manualmente este. Acaba de dejar de la manera que es. Es ACEPTAR y caja fuerte.

  2. 80

    Si usted realmente quiere hacer esto usted puede reenviar el tráfico en el puerto 80 a 3000.

    sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 3000
    • esto es genial! yo era ser capaz de solucionar el problema!
    • agradable y limpio respuesta sin nginx u otra solución de proxy!
    • Sea cuidadoso al usar este comando. Si usted ha iniciado sesión como root en el servidor, este se reenvía el tráfico en todos los dominios para el puerto 3000.
    • este comando derribado toda mi digitalocean servidor… sólo quería poner que fuera allí para los demás
    • es probable que haya tenido otro proceso que se ejecuta en ese puerto que fue una paliza cuando se le redirige 80 3000.
    • Funciona bien, pero me pregunto si no hay una solución más limpia? ¿Cuál es la mejor práctica?

  3. 0

    Tal vez hay algo de lo que se ejecuta en el puerto 80 anteriormente?

    Tal vez hacer un escaneo de puertos y confirmar que no está siendo usado ya?

    nc -z <<your IP>> 80
    • Yo no puedo pensar en nada. Es un nuevo ejemplo con una copia de node.js instalado y el servidor de mongodb en ejecución. nc devolvió nada.
  4. 0

    Mantenerlo Simple Estúpido:

    • netcap
    • systemd
    • VPS

    Normal, en una VPS (como Digital Ocean, Linode, Vultr, o Scaleway), en el que el disco es persistente, el uso de «netcap». Esto permitirá que un usuario no-root unen a los privilegiados de los puertos.

    sudo setcap 'cap_net_bind_service=+ep' $(which node)

    TADA! Ahora puede ejecutar node ./server.js --port 80 como un usuario normal!

    A un lado:

    También puede utilizar systemd para detener e iniciar el servicio. Desde systemd a veces es un p.yo.t.un., Escribí un contenedor de secuencia de comandos en Ir que hace que sea realmente fácil de implementar nodo de proyectos:

    # Install
    curl https://rootprojects.org/serviceman/dist/linux/amd64/serviceman -o serviceman
    chmod +x ./serviceman
    sudo serviceman /usr/local/bin
    # Use
    cd ./my/node/project
    sudo serviceman --username $(whoami) add npm start

    o, si su servidor no se llama ‘server.js’ (estándar de facto), o las opciones extra:

    cd ./my/node/project
    sudo serviceman --username $(whoami) add node ./my-server-thing.js -- --my-options

    Todo lo que hace es crear su systemd archivo con cuerdo valores predeterminados. Yo te recomiendo retirar el systemd documentación así, pero es un poco difícil de asimilar y probablemente hay más confuso y otra mala tutoriales que hay sencillos y buenos tutoriales.

    Efímero Casos (es decir, EC2) no son de larga duración servidores

    Generalmente, cuando la gente usa EC2, es porque no les importa acerca de la instancia de tiempo de actividad de la fiabilidad – quieren una «escalable» de la arquitectura, no es un persistente de la arquitectura.

    En la mayoría de estos casos no es la intención de que el servidor virtualizado persisten en cualquier tipo de camino. En estos tipos de «efímero» (temporal) de los entornos de un «reboot» está destinada a ser aproximadamente la misma que la reinstalación desde cero.

    No «configuración de un servidor», sino «implementar una imagen». La única razón por la que había iniciar sesión en un servidor es el prototipo de depuración o de la imagen que se está creando.

    Los «discos» son volátiles, las direcciones IP son flotantes, las imágenes se comportan de la misma en todos y cada arranque. Usted también no es normalmente el uso de un concepto de cuentas de usuario en el sentido tradicional.

    Por lo tanto: si bien es cierto que, en general, no debe ejecutar un servicio como root, los tipos de situaciones en las que normalmente se utilizan volátiles de virtualización… no importa mucho. Usted tiene un servicio único, de una sola cuenta de usuario, y tan pronto como la instancia falla o es de otra manera «reiniciado» (o que gire una nueva instancia de la imagen), tiene un sistema nuevo todo de nuevo (lo cual no significa que todas las vulnerabilidades que persisten).

    Firewalls: Efímero vs VPS

    Cosas como EC2 es generalmente la intención de ser privado, no en público. Se trata de «servicio en la nube» de los sistemas. Se espera que el uso de una docena de diferentes servicios y auto-escala. Como tal, tendría que utilizar el servicio de equilibrio de carga para la redirección de puertos para su EC2 grupo. Normalmente el cortafuegos por defecto para una instancia de negar todos los públicos-el tráfico de la red. Usted tiene que ir a la administración de firewall y asegúrese de que los puertos que piensa utilizar están realmente abiertos.

    A veces VPS tienen los proveedores de «empresa» firewall configuradores, pero por lo general usted acaba de conseguir el raw de acceso a la máquina virtual, ya que solo los puertos que realmente escuchar a tener acceso al mundo exterior en el primer lugar (por defecto que normalmente no tienen aleatoria de ejecución de servicios), usted no puede conseguir cualquier beneficio adicional de un firewall. Sin duda una buena idea, pero no es un requisito para hacer lo que usted necesita hacer.

    No uso EC2 como un VPS

    El caso de uso que han de arriba puede ser un mejor candidato para un tradicional servicio VPS (como se mencionó anteriormente: Digital Ocean, Linode, Vultr, Scaleway, etc) que son mucho más fáciles de utilizar y tienen mucho menos la gestión de molestia para empezar. Todo lo que necesitas es un poco de bash CLI know-how.

    Y, como un bono adicional, usted no tiene que adivinar cuál será el costo. Dicen que en la simple $/mes en lugar de ¢/cpu/hora/gb/interior-red/externo-red/etc – así que cuando algo sale mal te sale un aviso a través de correo electrónico o en su consola de administración en lugar de un inesperado factura por $6,527.

    Parte inferior de la línea de: Si usted elige utilizar EC2 y no eres un «DevOps» de expertos con un contador en el personal… vas a tener un tiempo difícil.

Dejar respuesta

Please enter your comment!
Please enter your name here