astra/ntfy
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
ntfy/docs/config-es.md
felipe 6fe00ca4d9 all md files translated to spanish 
Signed-off-by: felipe <ingenierofelipeurrego@gmail.com>
2022-06-23 22:14:35 -05:00

66 KiB
Raw Blame History

Configuración del servidor ntfy

El servidor ntfy se puede configurar de tres maneras: utilizando un archivo de configuración (normalmente en /etc/ntfy/server.yml, ver servidor.yml), a través de argumentos de línea de comandos o utilizando variables de entorno.

Inicio rápido

De forma predeterminada, simplemente ejecutando ntfy serve iniciará el servidor en el puerto 80. No se necesita configuración. Baterías incluidas 😀. Si todo funciona como debería, verás algo como esto:

$ ntfy serve
2021/11/30 19:59:08 Listening on :80

Puede comenzar inmediatamente publicar mensajes, o suscríbase a través del Aplicación para Android, la interfaz de usuario web, o simplemente a través de curl o tu cliente HTTP favorito. Para configurar el servidor además, echa un vistazo a la Tabla de opciones de configuración o simplemente escriba ntfy serve --help Para obtener una lista de opciones de línea de comandos.

Ejemplo de configuración

!!! información Definitivamente echa un vistazo al servidor.yml archivo. Contiene ejemplos y descripciones detalladas de todas las configuraciones.

Los ajustes más básicos son base-url (la URL externa del servidor ntfy), la dirección de escucha HTTP/HTTPS (listen-http y listen-https), y ruta de acceso de socket (listen-unix). Todas las demás cosas son características adicionales.

Aquí hay algunas configuraciones de ejemplo que funcionan:

=== "server.yml (sólo HTTP, con caché + archivos adjuntos)" yaml base-url: "http://ntfy.example.com" cache-file: "/var/cache/ntfy/cache.db" attachment-cache-dir: "/var/cache/ntfy/attachments"

=== "server.yml (HTTP+HTTPS, con caché + adjuntos)" yaml base-url: "http://ntfy.example.com" listen-http: ":80" listen-https: ":443" key-file: "/etc/letsencrypt/live/ntfy.example.com.key" cert-file: "/etc/letsencrypt/live/ntfy.example.com.crt" cache-file: "/var/cache/ntfy/cache.db" attachment-cache-dir: "/var/cache/ntfy/attachments"

=== "server.yml (ntfy.sh config)" ''' yaml # Todas las cosas: Detrás de un proxy, Firebase, caché, archivos adjuntos, # Publicación y recepción SMTP

base-url: "https://ntfy.sh"
listen-http: "127.0.0.1:2586"
firebase-key-file: "/etc/ntfy/firebase.json"
cache-file: "/var/cache/ntfy/cache.db"
behind-proxy: true
attachment-cache-dir: "/var/cache/ntfy/attachments"
smtp-sender-addr: "email-smtp.us-east-2.amazonaws.com:587"
smtp-sender-user: "AKIDEADBEEFAFFE12345"
smtp-sender-pass: "Abd13Kf+sfAk2DzifjafldkThisIsNotARealKeyOMG."
smtp-sender-from: "ntfy@ntfy.sh"
smtp-server-listen: ":25"
smtp-server-domain: "ntfy.sh"
smtp-server-addr-prefix: "ntfy-"
keepalive-interval: "45s"
```

Caché de mensajes

Si lo desea, ntfy puede mantener temporalmente las notificaciones en una memoria memoria o en una memoria caché en disco. Almacenamiento en caché de mensajes durante un período corto del tiempo es importante permitir Teléfonos y otros dispositivos con conexiones a Internet frágiles para poder recuperar notificaciones que pueden haberse perdido.

De forma predeterminada, ntfy mantiene los mensajes en memoria durante 12 horas, lo que significa que Los mensajes almacenados en caché no sobreviven a una aplicación reanudar. Puede invalidar este comportamiento mediante la siguiente configuración:

  • cache-file: si se establece, ntfy almacenará los mensajes en una memoria caché basada en SQLite (el valor predeterminado es vacío, lo que significa caché en memoria). Esto es necesario si desea que los mensajes se conserven durante los reinicios.
  • cache-duration: define la duración durante la cual se almacenan los mensajes en la memoria caché (el valor predeterminado es 12h).

También puede deshabilitar completamente la caché configurando cache-duration Para 0. Cuando la memoria caché está deshabilitada, los mensajes son sólo se transmite a los suscriptores conectados, pero nunca se almacena en el disco o incluso se mantiene en la memoria más tiempo del necesario para reenviar el mensaje a los suscriptores.

Los suscriptores pueden recuperar mensajes almacenados en caché mediante el poll=1 parámetro, así como el since= parámetro.

Accesorios

Si lo desea, puede permitir que los usuarios carguen y adjuntar archivos a las notificaciones. Para habilitar En esta característica, simplemente debe configurar un directorio de caché de datos adjuntos y una URL base (attachment-cache-dir, base-url). Una vez que se establecen estas opciones y el usuario del servidor puede escribir el directorio, puede cargar archivos adjuntos a través de PUT.

De forma predeterminada, los datos adjuntos se almacenan en la memoria caché de disco por solo 3 horas. La razón principal de esto es evitar problemas legales. y tales cuando se aloja contenido controlado por el usuario. Por lo general, este es un tiempo más que suficiente para el usuario (o la descarga automática) feature) para descargar el archivo. Las siguientes opciones de configuración son relevantes para los datos adjuntos:

  • base-url es la URL raíz del servidor ntfy; Esto es necesario para las direcciones URL de datos adjuntos generadas
  • attachment-cache-dir es el directorio de caché de los archivos adjuntos
  • attachment-total-size-limit es el límite de tamaño de la caché de datos adjuntos en disco (predeterminado: 5G)
  • attachment-file-size-limit es el límite de tamaño de datos adjuntos por archivo (por ejemplo, 300k, 2M, 100M, predeterminado: 15M)
  • attachment-expiry-duration es la duración después de la cual se eliminarán los archivos adjuntos cargados (por ejemplo, 3h, 20h, valor predeterminado: 3h)

Aquí hay un ejemplo de configuración que utiliza principalmente los valores predeterminados (excepto el directorio de caché, que está vacío de forma predeterminada):

=== "/etc/ntfy/server.yml (mínimo)" yaml base-url: "https://ntfy.sh" attachment-cache-dir: "/var/cache/ntfy/attachments"

=== "/etc/ntfy/server.yml (todas las opciones)" yaml base-url: "https://ntfy.sh" attachment-cache-dir: "/var/cache/ntfy/attachments" attachment-total-size-limit: "5G" attachment-file-size-limit: "15M" attachment-expiry-duration: "3h" visitor-attachment-total-size-limit: "100M" visitor-attachment-daily-bandwidth-limit: "500M"

Por favor, consulte también el limitación de velocidad configuración a continuación, específicamente visitor-attachment-total-size-limit y visitor-attachment-daily-bandwidth-limit. Establecerlos de manera conservadora es necesario para evitar el abuso.

Control de acceso

De forma predeterminada, el servidor ntfy está abierto para todos, lo que significa todo el mundo puede leer y escribir sobre cualquier tema (así es como ntfy.sh está configurado). Para restringir el acceso a su propio servidor, puede configurar opcionalmente la autenticación y la autorización.

La autenticación de ntfy se implementa con un simple SQLite-backend basado. Implementa dos roles (user y admin) y por tema read y write permisos mediante un lista de control de acceso (ACL). Las entradas de control de acceso se pueden aplicar a los usuarios, así como al usuario especial de todos (*), que representa el acceso anónimo a la API.

Para configurar la autenticación, simplemente Configure las dos opciones siguientes:

  • auth-file es la base de datos de usuario/acceso; se crea automáticamente si aún no existe; propuesto ubicación /var/lib/ntfy/user.db (más fácil si se utiliza el paquete deb/rpm)
  • auth-default-access define el acceso predeterminado/de reserva si no se encuentra ninguna entrada de control de acceso; puede ser establecer en read-write (por defecto), read-only, write-only o deny-all.

Una vez configurado, puede utilizar el ntfy user comando a agregar o modificar usuarios, y el ntfy access mandar le permite Modificar la lista de control de acceso para usuarios específicos y patrones de temas. Ambos Comandos Edite directamente la base de datos de autenticación (tal como se define en auth-file), por lo que solo funcionan en el servidor, y solo si el usuario acceder a ellos tiene los permisos correctos.

Usuarios y roles

El ntfy user Le permite agregar,quitar/cambiar usuarios en la base de datos de usuarios de Ntfy, así como cambiar contraseñas o roles (user o admin). En la práctica, a menudo solo creará un administrador usuario con ntfy user add --role=admin ... y hágase con todo esto (ver ejemplo a continuación).

Papeles:

  • Rol user (predeterminado): los usuarios con este rol no tienen permisos especiales. Administrar el acceso mediante ntfy access (ver abajo).
  • Rol admin: Los usuarios con este rol pueden leer/escribir en todos los temas. El control de acceso granular no es necesario.

Comandos de ejemplo (tipo ntfy user --help o ntfy user COMMAND --help para más detalles):

ntfy user list                     # Shows list of users (alias: 'ntfy access')
ntfy user add phil                 # Add regular user phil  
ntfy user add --role=admin phil    # Add admin user phil
ntfy user del phil                 # Delete user phil
ntfy user change-pass phil         # Change password for user phil
ntfy user change-role phil admin   # Make user phil an admin

Lista de control de acceso (ACL)

La lista de control de acceso (ACL) administra el acceso a los temas para los usuarios que no son administradores y para el acceso anónimo (everyone/*). Cada entrada representa los permisos de acceso de un usuario a un tema o patrón de tema específico.

La ACL se puede mostrar o modificar con el ntfy access mandar:

ntfy access                            # Shows access control list (alias: 'ntfy user list')
ntfy access USERNAME                   # Shows access control entries for USERNAME
ntfy access USERNAME TOPIC PERMISSION  # Allow/deny access for USERNAME to TOPIC

Un USERNAME es un usuario existente, tal como se creó con ntfy user add (ver usuarios y roles), o el usuario anónimo everyone o *, que representa a los clientes que acceden a la API sin nombre de usuario/contraseña.

Un TOPIC es un nombre de tema específico (por ejemplo, mytopico phil_alerts), o un patrón comodín que coincida con cualquier número de temas (por ejemplo, alerts_* o ben-*). Sólo el carácter comodín * es compatible. Significa cero a cualquier número de caracteres.

Un PERMISSION es cualquiera de los siguientes permisos admitidos:

  • read-write (alias: rw): Permite publicar mensajes al tema dado, así como Suscribirse y lectura de mensajes
  • read-only (alias: read, ro): Permite solo suscribirse y leer mensajes, pero no publicar en el tema
  • write-only (alias: write, wo): Permite publicar solo en el tema, pero no suscribirse a él
  • deny (alias: none): No permite publicar ni suscribirse a un tema

Comandos de ejemplo (tipo ntfy access --help para más detalles):

ntfy access                        # Shows entire access control list
ntfy access phil                   # Shows access for user phil
ntfy access phil mytopic rw        # Allow read-write access to mytopic for user phil
ntfy access everyone mytopic rw    # Allow anonymous read-write access to mytopic
ntfy access everyone "up*" write   # Allow anonymous write-only access to topics "up..."
ntfy access --reset                # Reset entire access control list
ntfy access --reset phil           # Reset all access for user phil
ntfy access --reset phil mytopic   # Reset access for user phil and topic mytopic

Ejemplo de ACL:

$ ntfy access
user phil (admin)
- read-write access to all topics (admin role)
user ben (user)
- read-write access to topic garagedoor
- read-write access to topic alerts*
- read-only access to topic furnace
user * (anonymous)
- read-only access to topic announcements
- read-only access to topic server-stats
- no access to any (other) topics (server config)

En este ejemplo, phil tiene el rol admin, por lo que tiene acceso de lectura y escritura a todos los temas (no se necesitan entradas de ACL). Usuario ben tiene tres entradas específicas del tema. Puede leer, pero no escribir sobre el tema furnace, y tiene acceso de lectura y escritura al tema garagedoor y todos los temas que comienzan con la palabra alerts (comodines). Clientes que no están autenticados (llamado */everyone) sólo tienen acceso de lectura a la announcements y server-stats Temas.

Ejemplo: Instancia privada

La forma más sencilla de configurar una instancia privada es establecer auth-default-access Para deny-all En server.yml:

=== "/etc/ntfy/server.yml" yaml auth-file: "/var/lib/ntfy/user.db" auth-default-access: "deny-all"

Después de eso, simplemente cree un admin usuario:

$ ntfy user add --role=admin phil
password: mypass
confirm: mypass
user phil added with role admin

Una vez que haya hecho eso, puede publicar y suscribirse usando Autenticación básica con el nombre de usuario/contraseña dado. Asegúrese de usar HTTPS para evitar espiar y exponer su contraseña. Aquí hay un ejemplo simple:

=== "Línea de comandos (curl)" curl \ -u phil:mypass \ -d "Look ma, with auth" \ https://ntfy.example.com/mysecrets

=== "ntfy CLI" ntfy publish \ -u phil:mypass \ ntfy.example.com/mysecrets \ "Look ma, with auth"

=== "HTTP" ''' http POST /mysecrets HTTP/1.1 Anfitrión: ntfy.example.com Autorización: Basic cGhpbDpteXBhc3M=

Look ma, with auth
```

=== "JavaScript" javascript fetch('https://ntfy.example.com/mysecrets', { method: 'POST', // PUT works too body: 'Look ma, with auth', headers: { 'Authorization': 'Basic cGhpbDpteXBhc3M=' } })

=== "Go" go req, _ := http.NewRequest("POST", "https://ntfy.example.com/mysecrets", strings.NewReader("Look ma, with auth")) req.Header.Set("Authorization", "Basic cGhpbDpteXBhc3M=") http.DefaultClient.Do(req)

=== "Python" python requests.post("https://ntfy.example.com/mysecrets", data="Look ma, with auth", headers={ "Authorization": "Basic cGhpbDpteXBhc3M=" })

=== "PHP" php-inline file_get_contents('https://ntfy.example.com/mysecrets', false, stream_context_create([ 'http' => [ 'method' => 'POST', // PUT also works 'header' => 'Content-Type: text/plain\r\n' . 'Authorization: Basic cGhpbDpteXBhc3M=', 'content' => 'Look ma, with auth' ] ]));

Notificaciones por correo electrónico

Para permitir el reenvío de mensajes por correo electrónico, puede configurar un Servidor SMTP para mensajes salientes. Una vez configurado, Puede establecer el X-Email encabezado a enviar mensajes por correo electrónico (por ejemplo, curl -d "hi there" -H "X-Email: phil@example.com" ntfy.sh/mytopic).

A partir de hoy, solo se admiten servidores SMTP con autenticación PLAIN y STARTLS. Para habilitar el envío de correo electrónico, debe establecer el siguientes configuraciones:

  • base-url es la URL raíz del servidor ntfy; Esto es necesario para el pie de página del correo electrónico
  • smtp-sender-addr es el nombre de host:puerto del servidor SMTP
  • smtp-sender-user y smtp-sender-pass son el nombre de usuario y la contraseña del usuario SMTP
  • smtp-sender-from es la dirección de correo electrónico del remitente

Aquí hay un ejemplo de configuración usando Amazon SES para el correo saliente (así es como es configurado para ntfy.sh):

=== "/etc/ntfy/server.yml" yaml base-url: "https://ntfy.sh" smtp-sender-addr: "email-smtp.us-east-2.amazonaws.com:587" smtp-sender-user: "AKIDEADBEEFAFFE12345" smtp-sender-pass: "Abd13Kf+sfAk2DzifjafldkThisIsNotARealKeyOMG." smtp-sender-from: "ntfy@ntfy.sh"

Por favor, consulte también el limitación de velocidad configuración a continuación, específicamente visitor-email-limit-burst y visitor-email-limit-burst. Establecerlos de manera conservadora es necesario para evitar el abuso.

Publicación de correo electrónico

Para permitir la publicación de mensajes por correo electrónico, ntfy puede ejecutar un Servidor SMTP para mensajes entrantes. Una vez configurado, los usuarios pueden enviar correos electrónicos a una dirección de correo electrónico de tema (por ejemplo, mytopic@ntfy.sh o myprefix-mytopic@ntfy.sh) para publicar mensajes en un tema. Esto es útil para integraciones basadas en correo electrónico, como statuspage.io (aunque en estos días la mayoría de los servicios también admiten webhooks y llamadas HTTP).

Para configurar el servidor SMTP, debe al menos establecer smtp-server-listen y smtp-server-domain:

  • smtp-server-listen define la dirección IP y el puerto en el que escuchará el servidor SMTP, por ejemplo. :25 o 1.2.3.4:25
  • smtp-server-domain es el dominio de correo electrónico, por ejemplo. ntfy.sh (debe ser idéntico al registro MX, ver más abajo)
  • smtp-server-addr-prefix es un prefijo opcional para las direcciones de correo electrónico para evitar el spam. Si se establece en ntfy-por ejemplo sólo envía correos electrónicos a ntfy-$topic@ntfy.sh será aceptado. Si esto no está configurado, todos los correos electrónicos a $topic@ntfy.sh será aceptado (que obviamente puede ser un problema de spam).

Aquí hay una configuración de ejemplo (así es como se configura para ntfy.sh):

=== "/etc/ntfy/server.yml" yaml smtp-server-listen: ":25" smtp-server-domain: "ntfy.sh" smtp-server-addr-prefix: "ntfy-"

Además de configurar el servidor ntfy, debe crear dos registros DNS (un Registro MX y un registro A correspondiente), por lo que el correo entrante llegará a su servidor. Aquí hay un ejemplo de cómo ntfy.sh es configurado (en Ruta de Amazon 53):

![DNS records for incoming mail](static/img/screenshot-email-publishing-dns.png){ width=600 }
DNS records for incoming mail

Puede verificar si todo funciona correctamente enviando un correo electrónico como SMTP sin procesar a través de nc. Crear un archivo de texto, por ejemplo. email.txt

EHLO example.com
MAIL FROM: phil@example.com
RCPT TO: ntfy-mytopic@ntfy.sh
DATA
Subject: Email for you
Content-Type: text/plain; charset="UTF-8"

Hello from 🇩🇪
.

Y luego enviar el correo a través de nc Así. Si ve alguna línea que comience por 451, esos son errores de la Servidor ntfy. Léalos detenidamente.

$ cat email.txt | nc -N ntfy.sh 25
220 ntfy.sh ESMTP Service Ready
250-Hello example.com
...
250 2.0.0 Roger, accepting mail from <phil@example.com>
250 2.0.0 I'll make sure <ntfy-mytopic@ntfy.sh> gets this

En cuanto a la configuración de DNS, asegúrese de verificar que dig MX y dig A están devolviendo resultados similares a este:

$ dig MX ntfy.sh +short 
10 mx1.ntfy.sh.
$ dig A mx1.ntfy.sh +short 
3.139.215.220

Detrás de un proxy (TLS, etc.)

!!! advertencia Si está ejecutando ntfy detrás de un proxy, debe establecer el behind-proxy bandera. De lo contrario, todos los visitantes son tarifa limitada como si fueran uno.

Puede ser deseable ejecutar ntfy detrás de un proxy (por ejemplo, nginx, HAproxy o Apache), para que pueda proporcionar certificados TLS usando Let's Encrypt usando certbot, o simplemente porque desea compartir los puertos (80/443) con otros servicios. Cualesquiera que sean sus razones, hay algunas cosas a considerar.

Si está ejecutando ntfy detrás de un proxy, debe establecer el behind-proxy bandera. Esto instruirá al limitación de velocidad lógica para utilizar el X-Forwarded-For encabezado como identificador principal para un visitante, a diferencia de la dirección IP remota. Si el behind-proxy la bandera no está configurada, todos los visitantes lo harán se cuentan como uno, porque desde la perspectiva del servidor ntfy, todos comparten la dirección IP del proxy.

=== "/etc/ntfy/server.yml" yaml # Tell ntfy to use "X-Forwarded-For" to identify visitors behind-proxy: true

TLS/SSL

Ntfy admite HTTPS/TLS estableciendo el listen-https opción de configuración. Sin embargo, si usted están detrás de un proxy, se recomienda que la terminación TLS / SSL sea realizada por el propio proxy (ver más abajo).

Recomiendo encarecidamente usar certbot. Lo uso con el Complemento dns-route53, que le permite usar Ruta 53 de AWS como el reto. Eso es mucho más fácil que usar el Desafío HTTP. He encontrado esta guía Para ser increíblemente útil.

nginx/Apache2/caddy

Para su comodidad, aquí hay una configuración de trabajo que ayudará a configurar las cosas detrás de un proxy. Asegúrese de habilitar WebSockets reenviando el Connection y Upgrade encabezados en consecuencia.

En este ejemplo, ntfy se ejecuta en :2586 y le enviamos el tráfico. También redirigimos HTTP a HTTPS para solicitudes GET contra un tema o el dominio raíz:

=== "nginx (/etc/nginx/sites-*/ntfy)" ``` servidor { escuchar 80; server_name ntfy.sh;

  location / {
    # Redirect HTTP to HTTPS, but only for GET topic addresses, since we want 
    # it to work with curl without the annoying https:// prefix
    set $redirect_https "";
    if ($request_method = GET) {
      set $redirect_https "yes";
    }
    if ($request_uri ~* "^/([-_a-z0-9]{0,64}$|docs/|static/)") {
      set $redirect_https "${redirect_https}yes";
    }
    if ($redirect_https = "yesyes") {
      return 302 https://$http_host$request_uri$is_args$query_string;
    }

    proxy_pass http://127.0.0.1:2586;
    proxy_http_version 1.1;

    proxy_buffering off;
    proxy_request_buffering off;
    proxy_redirect off;
 
    proxy_set_header Host $http_host;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    proxy_connect_timeout 3m;
    proxy_send_timeout 3m;
    proxy_read_timeout 3m;

    client_max_body_size 20m; # Must be >= attachment-file-size-limit in /etc/ntfy/server.yml
  }
}

server {
  listen 443 ssl;
  server_name ntfy.sh;

  ssl_session_cache builtin:1000 shared:SSL:10m;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
  ssl_prefer_server_ciphers on;

  ssl_certificate /etc/letsencrypt/live/ntfy.sh/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/ntfy.sh/privkey.pem;

  location / {
    proxy_pass http://127.0.0.1:2586;
    proxy_http_version 1.1;

    proxy_buffering off;
    proxy_request_buffering off;
    proxy_redirect off;
 
    proxy_set_header Host $http_host;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    proxy_connect_timeout 3m;
    proxy_send_timeout 3m;
    proxy_read_timeout 3m;
    
    client_max_body_size 20m; # Must be >= attachment-file-size-limit in /etc/ntfy/server.yml
  }
}
```

=== "Apache2 (/etc/apache2/sites-*/ntfy.conf)" ``` <VirtualHost *:80> ServerName ntfy.sh

    # Proxy connections to ntfy (requires "a2enmod proxy")
    ProxyPass / http://127.0.0.1:2586/
    ProxyPassReverse / http://127.0.0.1:2586/

    SetEnv proxy-nokeepalive 1
    SetEnv proxy-sendchunked 1

    # Higher than the max message size of 4096 bytes
    LimitRequestBody 102400

    # Enable mod_rewrite (requires "a2enmod rewrite")
    RewriteEngine on

    # WebSockets support (requires "a2enmod rewrite proxy_wstunnel")
    RewriteCond %{HTTP:Upgrade} websocket [NC]
    RewriteCond %{HTTP:Connection} upgrade [NC]
    RewriteRule ^/?(.*) "ws://127.0.0.1:2586/$1" [P,L]
    
    # Redirect HTTP to HTTPS, but only for GET topic addresses, since we want 
    # it to work with curl without the annoying https:// prefix 
    RewriteCond %{REQUEST_METHOD} GET
    RewriteRule ^/([-_A-Za-z0-9]{0,64})$ https://%{SERVER_NAME}/$1 [R,L]
</VirtualHost>

<VirtualHost *:443>
    ServerName ntfy.sh
    
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/ntfy.sh/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/ntfy.sh/privkey.pem
    Include /etc/letsencrypt/options-ssl-apache.conf

    # Proxy connections to ntfy (requires "a2enmod proxy")
    ProxyPass / http://127.0.0.1:2586/
    ProxyPassReverse / http://127.0.0.1:2586/

    SetEnv proxy-nokeepalive 1
    SetEnv proxy-sendchunked 1

    # Higher than the max message size of 4096 bytes 
    LimitRequestBody 102400

    # Enable mod_rewrite (requires "a2enmod rewrite")
    RewriteEngine on

    # WebSockets support (requires "a2enmod rewrite proxy_wstunnel")
    RewriteCond %{HTTP:Upgrade} websocket [NC]
    RewriteCond %{HTTP:Connection} upgrade [NC]
    RewriteRule ^/?(.*) "ws://127.0.0.1:2586/$1" [P,L] 
</VirtualHost>
```

=== "caddy" ``` # Tenga en cuenta que esta configuración es ciertamente incompleta. Por favor, ayúdame y hazme saber lo que falta # a través de Discord/Matrix o en un problema de GitHub.

ntfy.sh, http://nfty.sh {
    reverse_proxy 127.0.0.1:2586

    # Redirect HTTP to HTTPS, but only for GET topic addresses, since we want
    # it to work with curl without the annoying https:// prefix
    @httpget {
        protocol http
        method GET
        path_regexp ^/([-_a-z0-9]{0,64}$|docs/|static/)
    }
    redir @httpget https://{host}{uri}
}
```

Base de fuego (FCM)

!!! información El uso de Firebase es opcional y solo funciona si modifica y crea tu propio .apk Android. Para una instancia autohospedada, es más fácil simplemente no molestarse con FCM.

Mensajería en la nube de Firebase (FCM) es la forma aprobada por Google para enviar enviar mensajes a dispositivos Android. FCM es el único método que una aplicación de Android puede recibir mensajes sin tener que ejecutar un servicio en primer plano.

Para el host principal ntfy.shel Aplicación ntfy para Android utiliza Firebase para enviar mensajes al dispositivo. Para otros hosts, se utiliza la entrega instantánea y FCM no está involucrado.

Para configurar FCM para la instancia autohospedada del servidor ntfy, siga estos pasos:

  1. Regístrese para un Cuenta de Firebase
  2. Crea una aplicación de Firebase y descarga el archivo de claves (por ejemplo, myapp-firebase-adminsdk-...json)
  3. Coloque el archivo de clave en /etc/ntfy, establezca el firebase-key-file en server.yml en consecuencia, reinicie el servidor NTFY
  4. Crea tu propio Android .apk siguiente Estas instrucciones

Ejemplo:

# If set, also publish messages to a Firebase Cloud Messaging (FCM) topic for your app.
# This is optional and only required to support Android apps (which don't allow background services anymore).
#
firebase-key-file: "/etc/ntfy/ntfy-sh-firebase-adminsdk-ahnce-9f4d6f14b5.json"

Notificaciones instantáneas de iOS

A diferencia de Android, iOS restringe en gran medida el procesamiento en segundo plano, lo que lamentablemente hace que sea imposible implementar el procesamiento instantáneo. notificaciones push sin un servidor central.

Para seguir admitiendo notificaciones instantáneas en iOS a través de su servidor ntfy autohospedado, debe reenviar los llamados poll_request mensajes al servidor principal de ntfy.sh (o a cualquier servidor ascendente que esté conectado a APNS/Firebase, si creas tu propia aplicación iOS), que luego lo reenviará a Firebase/APNS.

Para configurarlo, simplemente configure upstream-base-url de esta manera:

upstream-base-url: "https://ntfy.sh"

Si se establece, todos los mensajes entrantes publicarán una solicitud de sondeo en el servidor ascendente configurado, que contiene el identificador de mensaje del mensaje original, que indica a la aplicación iOS que sondee este servidor en busca del contenido real del mensaje.

Si upstream-base-url no está configurado, las notificaciones llegarán eventualmente a su dispositivo, pero la entrega puede tardar horas, dependiendo del estado del teléfono. Sin embargo, si está usando su teléfono, no debería tomar más de 20-30 minutos.

En caso de que tengas curiosidad, aquí hay un ejemplo de todo el flujo:

  • En la aplicación iOS, te suscribes a https://ntfy.example.com/mytopic
  • La aplicación se suscribe al tema de Firebase 6de73be8dfb7d69e... (el SHA256 de la URL del tema)
  • Al publicar un mensaje en https://ntfy.example.com/mytopic, el servidor NTFY publicará un solicitud de sondeo a https://ntfy.sh/6de73be8dfb7d69e.... La solicitud de su servidor al servidor ascendente contiene sólo el identificador de mensaje (en el cuadro de diálogo X-Poll-ID encabezado), y la suma de comprobación SHA256 de la dirección URL del tema (como tema ascendente).
  • El servidor de ntfy.sh publica el mensaje de solicitud de sondeo en Firebase, que lo reenvía a APNS, que lo reenvía a tu dispositivo iOS.
  • Su dispositivo iOS recibe la solicitud de sondeo y obtiene el mensaje real de su servidor y, a continuación, lo muestra

Aquí hay un ejemplo de lo que el servidor autohospedado reenvía al servidor ascendente. La solicitud es equivalente a este rizo:

curl -X POST -H "X-Poll-ID: s4PdJozxM8na" https://ntfy.sh/6de73be8dfb7d69e32fb2c00c23fe7adbd8b5504406e3068c273aa24cef4055b
{"id":"4HsClFEuCIcs","time":1654087955,"event":"poll_request","topic":"6de73be8dfb7d69e32fb2c00c23fe7adbd8b5504406e3068c273aa24cef4055b","message":"New message","poll_id":"s4PdJozxM8na"}

Limitación de velocidad

!!! información Tenga en cuenta que si está ejecutando ntfy detrás de un proxy, debe establecer el behind-proxy bandera. De lo contrario, todos los visitantes están limitados por la tarifa como si fueran uno.

De forma predeterminada, ntfy se ejecuta sin autenticación, por lo que es de vital importancia que protejamos el servidor del abuso o la sobrecarga. Existen varios límites y límites de velocidad que puede utilizar para configurar el servidor:

  • Límite global: Se aplica un límite global a todos los visitantes (IP, clientes, usuarios)
  • Límite de visitantes: Un límite de visitantes solo se aplica a un determinado visitante. Un visitante se identifica por su dirección IP (o el X-Forwarded-For encabezado si behind-proxy está configurado). Todas las opciones de configuración que comienzan con la palabra visitor aplicar solo por visitante.

Durante el uso normal, no debería encontrar estos límites en absoluto, e incluso si revienta algunas solicitudes o correos electrónicos. (por ejemplo, cuando se vuelve a conectar después de una caída de la conexión), no debería tener ningún efecto.

Límites generales

Hagamos primero los límites fáciles:

  • global-topic-limit define el número total de temas antes de que el servidor rechace nuevos temas. El valor predeterminado es 15.000.
  • visitor-subscription-limit es el número de suscripciones (conexiones abiertas) por visitante. Este valor predeterminado es 30.

Límites de solicitud

Además de los límites anteriores, hay un límite de solicitudes / segundo por visitante para todas las solicitudes sensibles GET / PUT / POST. Este límite utiliza un bucket de tokens (usando Go's paquete de tarifas):

Cada visitante tiene un bucket de 60 solicitudes que pueden disparar contra el servidor (definidas por visitor-request-limit-burst). Después de los 60, las nuevas solicitudes se encontrarán con un 429 Too Many Requests respuesta. El cubo de solicitud de visitante se rellena a una velocidad de uno solicitud cada 5s (definida por visitor-request-limit-replenish)

  • visitor-request-limit-burst es el cubo inicial de solicitudes que tiene cada visitante. El valor predeterminado es 60.
  • visitor-request-limit-replenish es la velocidad a la que se rellena el bucket (una solicitud por x). El valor predeterminado es 5s.
  • visitor-request-limit-exempt-hosts es una lista separada por comas de nombres de host e IP que deben estar exentos de la tasa de solicitud limitante; los nombres de host se resuelven en el momento en que se inicia el servidor. El valor predeterminado es una lista vacía.

Límites de datos adjuntos

Aparte del tamaño global del archivo y los límites totales de caché de datos adjuntos (consulte encima), hay dos relevantes Límites por visitante:

  • visitor-attachment-total-size-limit es el límite total de almacenamiento utilizado para los archivos adjuntos por visitante. El valor predeterminado es 100M. El almacenamiento por visitante se reduce automáticamente a medida que expiran los archivos adjuntos. Accesorios externos (conectados a través de X-Attach, ver publicar documentos) no cuentan aquí.
  • visitor-attachment-daily-bandwidth-limit es el límite total diario de ancho de banda de descarga/carga de archivos adjuntos por visitante, incluidas las solicitudes PUT y GET. Esto es para proteger su valioso ancho de banda del abuso, ya que la salida cuesta dinero en la mayoría de los proveedores de nube. El valor predeterminado es 500M.

Límites de correo electrónico

De manera similar al límite de solicitudes, también hay un límite de correo electrónico (solo relevante si notificaciones por correo electrónico están habilitados):

  • visitor-email-limit-burst es el cubo inicial de correos electrónicos que tiene cada visitante. El valor predeterminado es 16.
  • visitor-email-limit-replenish es la velocidad a la que se rellena el bucket (un correo electrónico por x). El valor predeterminado es 1h.

Límites de Firebase

Si Firebase está configurado, todos los mensajes también se publican en un tema de Firebase (a menos que Firebase: no está configurado). Firebase aplica sus propios límites sobre cuántos mensajes se pueden publicar. Desafortunadamente, estos límites son un poco vagos y pueden cambiar dependiendo del tiempo. del día. En la práctica, solo he observado 429 Quota exceeded respuestas de Firebase si Se publican demasiados mensajes en el mismo tema.

En ntfy, si Firebase responde con un 429 después de publicar en un tema, el visitante (= dirección IP) que publicó el mensaje es se prohibió publicar en Firebase durante 10 minutos (no configurable). Debido a que la publicación en Firebase se realiza de forma asincrónica, no hay ninguna indicación del usuario de que esto haya sucedido. Los suscriptores que no son de Firebase (WebSocket o HTTP stream) no se ven afectados. Después de los 10 minutos, se reanuda el reenvío de mensajes a Firebase para este visitante.

Si esto sucede alguna vez, habrá un mensaje de registro que se ve algo como esto:

WARN Firebase quota exceeded (likely for topic), temporarily denying Firebase access to visitor

Ajuste para escala

Si está ejecutando ntfy para su servidor doméstico, probablemente no tenga que preocuparse por la escala en absoluto. En su configuración predeterminada, Si no está detrás de un proxy, el servidor NTFY puede mantener aproximadamente tantas conexiones como permita el límite de archivos abiertos. Este límite se suele denominar nofile. Aparte de eso, la RAM y la CPU son obviamente relevantes. También es posible que desee verificar fuera esta discusión en Reddit.

Según cómo lo ejecuta, aquí hay algunos límites que son relevantes:

WAL para caché de mensajes

De forma predeterminada, el caché de mensajes (definido por cache-file) utiliza la configuración predeterminada de SQLite, lo que significa que se sincroniza con el disco en cada escritura. Para servidores personales, esto es perfectamente adecuado. Para instalaciones más grandes, como ntfy.sh, el registro de escritura anticipada (WAL) debe estar habilitado y el modo de sincronización debe ajustarse. Ver este artículo para más detalles.

Así es como se ha sintonizado ntfy.sh en el server.yml archivo:

cache-startup-queries: |
    pragma journal_mode = WAL;
    pragma synchronous = normal;
    pragma temp_store = memory;

Para servicios systemd

Si está ejecutando ntfy en un servicio systemd (por ejemplo, para paquetes de .deb/.rpm), el principal factor limitante es el LimitNOFILE en la unidad systemd. El límite predeterminado de archivos abiertos para ntfy.service es 10.000. Puede anularlo mediante la creación de un /etc/systemd/system/ntfy.service.d/override.conf archivo. Por lo que puedo decir, /etc/security/limits.conf no es relevante.

=== "/etc/systemd/system/ntfy.service.d/override.conf" # Allow 20,000 ntfy connections (and give room for other file handles) [Service] LimitNOFILE=20500

Fuera de systemd

Si está ejecutando fuera de systemd, es posible que desee ajustar su /etc/security/limits.conf archivo a aumentar el nofile ajuste. Aquí hay un ejemplo que aumenta el límite a 5,000. Puede averiguar la configuración actual corriendo ulimit -n, o anule manualmente temporalmente ejecutando ulimit -n 50000.

=== "/etc/security/limits.conf" # Increase open files limit globally * hard nofile 20500

Límites de proxy (nginx, Apache2)

Si estás corriendo detrás de un proxy (por ejemplo, nginx, Apache), el límite de archivos abiertos del proxy también es pertinente. Entonces, si su proxy se ejecuta dentro de systemd, aumente los límites en systemd para el proxy. Normalmente, el proxy El límite de archivos abiertos tiene que ser Duplique el número de conexiones que desea admitir, porque el proxy tiene para mantener la conexión del cliente y la conexión con ntfy.

=== "/etc/nginx/nginx.conf" events { # Allow 40,000 proxy connections (2x of the desired ntfy connection count; # and give room for other file handles) worker_connections 40500; }

=== "/etc/systemd/system/nginx.service.d/override.conf" # Allow 40,000 proxy connections (2x of the desired ntfy connection count; # and give room for other file handles) [Service] LimitNOFILE=40500

Prohibir a los malos actores (fail2ban)

Si pones cosas en Internet, los malos actores intentarán romperlas o irrumpir. fail2ban y nginx's ngx_http_limit_req_module módulo se puede utilizar prohibir las IP de los clientes si se comportan mal. Esto está en la parte superior de la limitación de velocidad dentro del servidor ntfy.

Aquí hay un ejemplo de cómo se configura ntfy.sh, siguiendo las instrucciones de dos tutoriales (aquí y aquí):

=== "/etc/nginx/nginx.conf" http { limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s; }

=== "/etc/nginx/sites-enabled/ntfy.sh" # For each server/location block server { location / { limit_req zone=one burst=1000 nodelay; } }

=== "/etc/fail2ban/filter.d/nginx-req-limit.conf" [Definition] failregex = limiting requests, excess:.* by zone.*client: <HOST> ignoreregex =

=== "/etc/fail2ban/jail.local" [nginx-req-limit] enabled = true filter = nginx-req-limit action = iptables-multiport[name=ReqLimit, port="http,https", protocol=tcp] logpath = /var/log/nginx/error.log findtime = 600 bantime = 7200 maxretry = 10

Depuración/rastreo

Si algo no funciona correctamente, puede depurar / rastrear lo que está haciendo el servidor ntfy configurando el log-level Para DEBUG o TRACE. El DEBUG Establecer generará información sobre cada mensaje publicado, pero no el mensaje contenido. El TRACE también imprimirá el contenido del mensaje.

!!! advertencia Ambas opciones son muy detalladas y solo deben habilitarse en producción durante cortos períodos de tiempo. De otra manera te vas a quedar sin espacio en disco bastante rápido.

También puede recargar en caliente el log-level enviando el SIGHUP señal al proceso después de editar el server.yml archivo. Puedes hacerlo llamando systemctl reload ntfy (si ntfy se ejecuta dentro de systemd), o llamando kill -HUP $(pidof ntfy). Si tiene éxito, verá algo como esto:

$ ntfy serve
2022/06/02 10:29:28 INFO Listening on :2586[http] :1025[smtp], log level is INFO
2022/06/02 10:29:34 INFO Partially hot reloading configuration ...
2022/06/02 10:29:34 INFO Log level is TRACE

Opciones de configuración

Cada opción de configuración se puede establecer en el archivo de configuración /etc/ntfy/server.yml (por ejemplo, listen-http: :80) o como Opción CLI (por ejemplo, --listen-http :80. Aquí hay una lista de todas las opciones disponibles. Como alternativa, puede establecer un entorno antes de ejecutar el ntfy comando (por ejemplo, export NTFY_LISTEN_HTTP=:80).

!!! información Todas las opciones de configuración también se pueden definir en el server.yml archivo que utiliza guiones bajos en lugar de guiones, por ejemplo. cache_duration y cache-duration ambos son compatibles. Esto es para admitir analizadores YAML más estrictos que lo hacen. no soporta guiones.

de opciones de configuración de variables Env Formato predeterminada Descripción
base-url NTFY_BASE_URL URL - URL base pública del servicio (por ejemplo, https://ntfy.sh)
listen-http NTFY_LISTEN_HTTP [host]:port :80 Dirección de escucha para el servidor web HTTP
listen-https NTFY_LISTEN_HTTPS [host]:port - Dirección de escucha para el servidor web HTTPS. Si está configurado, también debe configurar key-file y cert-file.
listen-unix NTFY_LISTEN_UNIX Nombre - Ruta a un socket Unix para escuchar en
key-file NTFY_KEY_FILE Nombre - Archivo de clave privada HTTPS/TLS, solo se usa si listen-https está configurado.
cert-file NTFY_CERT_FILE Nombre - Archivo de certificado HTTPS/TLS, solo se usa si listen-https está configurado.
firebase-key-file NTFY_FIREBASE_KEY_FILE Nombre - Si está configurado, publica también mensajes en un tema de Firebase Cloud Messaging (FCM) para tu aplicación. Esto es opcional y solo es necesario para ahorrar batería cuando se usa la aplicación de Android. Ver Base de fuego (FCM).
cache-file NTFY_CACHE_FILE Nombre - Si se establece, los mensajes se almacenan en caché en una base de datos SQLite local en lugar de solo en memoria. Esto permite reiniciar el servicio sin perder mensajes en apoyo del parámetro since=. Ver caché de mensajes.
cache-duration NTFY_CACHE_DURATION duración 12h Duración durante la cual los mensajes se almacenarán en búfer antes de que se eliminen. Esto es necesario para apoyar el since=... y poll=1 parámetro. Establezca esto en 0 para deshabilitar la memoria caché por completo.
cache-startup-queries NTFY_CACHE_STARTUP_QUERIES cadena (consultas SQL) - Consultas SQL para ejecutar durante el inicio de la base de datos; Esto es útil para ajustar y habilitar el modo WAL
auth-file NTFY_AUTH_FILE Nombre - Archivo de base de datos de autenticación utilizado para el control de acceso. Si se establece, habilita la autenticación y el control de acceso. Ver control de acceso.
auth-default-access NTFY_AUTH_DEFAULT_ACCESS read-write, read-only, write-only, deny-all read-write Permisos predeterminados si no se encuentran entradas coincidentes en la base de datos de autenticación. El valor predeterminado es read-write.
behind-proxy NTFY_BEHIND_PROXY Bool falso Si se establece, el encabezado X-Forwarded-For se utiliza para determinar la dirección IP del visitante en lugar de la dirección remota de la conexión.
attachment-cache-dir NTFY_ATTACHMENT_CACHE_DIR directorio - Directorio de caché para archivos adjuntos. Para habilitar los archivos adjuntos, esto debe establecerse.
attachment-total-size-limit NTFY_ATTACHMENT_TOTAL_SIZE_LIMIT tamaño 5G Límite del directorio de caché de datos adjuntos en disco. Si se superan los límites, se rechazarán los nuevos archivos adjuntos.
attachment-file-size-limit NTFY_ATTACHMENT_FILE_SIZE_LIMIT tamaño 15M Límite de tamaño de archivos adjuntos por archivo (por ejemplo, 300k, 2M, 100M). Se rechazará el archivo adjunto más grande.
attachment-expiry-duration NTFY_ATTACHMENT_EXPIRY_DURATION duración 3h Duración después de la cual se eliminarán los archivos adjuntos cargados (por ejemplo, 3h, 20h). Afecta fuertemente visitor-attachment-total-size-limit.
smtp-sender-addr NTFY_SMTP_SENDER_ADDR host:port - Dirección del servidor SMTP para permitir el envío de correo electrónico
smtp-sender-user NTFY_SMTP_SENDER_USER cuerda - Usuario SMTP; sólo se utiliza si el envío de correo electrónico está habilitado
smtp-sender-pass NTFY_SMTP_SENDER_PASS cuerda - Contraseña SMTP; sólo se utiliza si el envío de correo electrónico está habilitado
smtp-sender-from NTFY_SMTP_SENDER_FROM dirección de correo electrónico - Dirección de correo electrónico del remitente SMTP; sólo se utiliza si el envío de correo electrónico está habilitado
smtp-server-listen NTFY_SMTP_SERVER_LISTEN [ip]:port - Define la dirección IP y el puerto en el que escuchará el servidor SMTP, por ejemplo. :25 o 1.2.3.4:25
smtp-server-domain NTFY_SMTP_SERVER_DOMAIN nombre de dominio - Dominio de correo electrónico del servidor SMTP, por ejemplo. ntfy.sh
smtp-server-addr-prefix NTFY_SMTP_SERVER_ADDR_PREFIX [ip]:port - Prefijo opcional para las direcciones de correo electrónico para evitar el spam, por ejemplo. ntfy-
keepalive-interval NTFY_KEEPALIVE_INTERVAL duración 45s Intervalo en el que se envían mensajes keepalive al cliente. Esto es para evitar que los intermediarios cierren la conexión por inactividad. Tenga en cuenta que la aplicación de Android tiene un tiempo de espera codificado en 77s, por lo que debería ser menor que eso.
manager-interval $NTFY_MANAGER_INTERVAL duración 1m de Intervalo en el que el administrador poda los mensajes antiguos, elimina los temas e imprime las estadísticas.
global-topic-limit NTFY_GLOBAL_TOPIC_LIMIT número 15.000 Limitación de velocidad: número total de temas antes de que el servidor rechace nuevos temas.
upstream-base-url NTFY_UPSTREAM_BASE_URL URL https://ntfy.sh Reenviar la solicitud de sondeo a un servidor ascendente, esto es necesario para las notificaciones push de iOS para servidores autohospedados
visitor-attachment-total-size-limit NTFY_VISITOR_ATTACHMENT_TOTAL_SIZE_LIMIT tamaño 100M Limitación de velocidad: Límite de almacenamiento total utilizado para archivos adjuntos por visitante, para todos los archivos adjuntos combinados. El almacenamiento se libera después de que expiran los archivos adjuntos. Ver attachment-expiry-duration.
visitor-attachment-daily-bandwidth-limit NTFY_VISITOR_ATTACHMENT_DAILY_BANDWIDTH_LIMIT tamaño 500M Limitación de velocidad: Límite total de tráfico diario de descarga/carga de archivos adjuntos por visitante. Esto es para proteger sus costos de ancho de banda de la explosión.
visitor-email-limit-burst NTFY_VISITOR_EMAIL_LIMIT_BURST número 16 Limitación de velocidad: Límite inicial de correos electrónicos por visitante
visitor-email-limit-replenish NTFY_VISITOR_EMAIL_LIMIT_REPLENISH duración 1h Limitación de velocidad: Fuertemente relacionado con visitor-email-limit-burst: La velocidad a la que se rellena el cubo
visitor-request-limit-burst NTFY_VISITOR_REQUEST_LIMIT_BURST número 60 Limitación de velocidad: Solicitudes GET/PUT/POST permitidas por segundo, por visitante. Esta configuración es el grupo inicial de solicitudes que cada visitante ha
visitor-request-limit-replenish NTFY_VISITOR_REQUEST_LIMIT_REPLENISH duración 5s Limitación de velocidad: Fuertemente relacionado con visitor-request-limit-burst: La velocidad a la que se rellena el cubo
visitor-request-limit-exempt-hosts NTFY_VISITOR_REQUEST_LIMIT_EXEMPT_HOSTS lista de hosts/IP separados por comas - Limitación de velocidad: Lista de nombres de host e IP que estarán exentos de la limitación de velocidad de solicitud
visitor-subscription-limit NTFY_VISITOR_SUBSCRIPTION_LIMIT número 30 Limitación de velocidad: Número de suscripciones por visitante (dirección IP)
web-root NTFY_WEB_ROOT app, home o disable app Establece la raíz web en la página de destino (inicio), la aplicación web (aplicación) o deshabilita la aplicación web por completo (deshabilitar)

El formato de un duración es: <number>(smh), por ejemplo, 30s, 20m o 1h.
El formato de un tamaño es: <number>(GMK), por ejemplo, 1G, 200M o 4000k.

Opciones de línea de comandos

$ ntfy serve --help
NAME:
   ntfy serve - Run the ntfy server

USAGE:
   ntfy serve [OPTIONS..]

CATEGORY:
   Server commands

DESCRIPTION:
   Run the ntfy server and listen for incoming requests
   
   The command will load the configuration from /etc/ntfy/server.yml. Config options can 
   be overridden using the command line options.
   
   Examples:
     ntfy serve                      # Starts server in the foreground (on port 80)
     ntfy serve --listen-http :8080  # Starts server with alternate port

OPTIONS:
   --attachment-cache-dir value, --attachment_cache_dir value                                          cache directory for attached files [$NTFY_ATTACHMENT_CACHE_DIR]
   --attachment-expiry-duration value, --attachment_expiry_duration value, -X value                    duration after which uploaded attachments will be deleted (e.g. 3h, 20h) (default: 3h) [$NTFY_ATTACHMENT_EXPIRY_DURATION]
   --attachment-file-size-limit value, --attachment_file_size_limit value, -Y value                    per-file attachment size limit (e.g. 300k, 2M, 100M) (default: 15M) [$NTFY_ATTACHMENT_FILE_SIZE_LIMIT]
   --attachment-total-size-limit value, --attachment_total_size_limit value, -A value                  limit of the on-disk attachment cache (default: 5G) [$NTFY_ATTACHMENT_TOTAL_SIZE_LIMIT]
   --auth-default-access value, --auth_default_access value, -p value                                  default permissions if no matching entries in the auth database are found (default: "read-write") [$NTFY_AUTH_DEFAULT_ACCESS]
   --auth-file value, --auth_file value, -H value                                                      auth database file used for access control [$NTFY_AUTH_FILE]
   --base-url value, --base_url value, -B value                                                        externally visible base URL for this host (e.g. https://ntfy.sh) [$NTFY_BASE_URL]
   --behind-proxy, --behind_proxy, -P                                                                  if set, use X-Forwarded-For header to determine visitor IP address (for rate limiting) (default: false) [$NTFY_BEHIND_PROXY]
   --cache-duration since, --cache_duration since, -b since                                            buffer messages for this time to allow since requests (default: 12h0m0s) [$NTFY_CACHE_DURATION]
   --cache-file value, --cache_file value, -C value                                                    cache file used for message caching [$NTFY_CACHE_FILE]
   --cache-startup-queries value, --cache_startup_queries value                                        queries run when the cache database is initialized [$NTFY_CACHE_STARTUP_QUERIES]
   --cert-file value, --cert_file value, -E value                                                      certificate file, if listen-https is set [$NTFY_CERT_FILE]
   --config value, -c value                                                                            config file (default: /etc/ntfy/server.yml) [$NTFY_CONFIG_FILE]
   --debug, -d                                                                                         enable debug logging (default: false) [$NTFY_DEBUG]
   --firebase-key-file value, --firebase_key_file value, -F value                                      Firebase credentials file; if set additionally publish to FCM topic [$NTFY_FIREBASE_KEY_FILE]
   --global-topic-limit value, --global_topic_limit value, -T value                                    total number of topics allowed (default: 15000) [$NTFY_GLOBAL_TOPIC_LIMIT]
   --keepalive-interval value, --keepalive_interval value, -k value                                    interval of keepalive messages (default: 45s) [$NTFY_KEEPALIVE_INTERVAL]
   --key-file value, --key_file value, -K value                                                        private key file, if listen-https is set [$NTFY_KEY_FILE]
   --listen-http value, --listen_http value, -l value                                                  ip:port used to as HTTP listen address (default: ":80") [$NTFY_LISTEN_HTTP]
   --listen-https value, --listen_https value, -L value                                                ip:port used to as HTTPS listen address [$NTFY_LISTEN_HTTPS]
   --listen-unix value, --listen_unix value, -U value                                                  listen on unix socket path [$NTFY_LISTEN_UNIX]
   --log-level value, --log_level value                                                                set log level (default: "INFO") [$NTFY_LOG_LEVEL]
   --manager-interval value, --manager_interval value, -m value                                        interval of for message pruning and stats printing (default: 1m0s) [$NTFY_MANAGER_INTERVAL]
   --no-log-dates, --no_log_dates                                                                      disable the date/time prefix (default: false) [$NTFY_NO_LOG_DATES]
   --smtp-sender-addr value, --smtp_sender_addr value                                                  SMTP server address (host:port) for outgoing emails [$NTFY_SMTP_SENDER_ADDR]
   --smtp-sender-from value, --smtp_sender_from value                                                  SMTP sender address (if e-mail sending is enabled) [$NTFY_SMTP_SENDER_FROM]
   --smtp-sender-pass value, --smtp_sender_pass value                                                  SMTP password (if e-mail sending is enabled) [$NTFY_SMTP_SENDER_PASS]
   --smtp-sender-user value, --smtp_sender_user value                                                  SMTP user (if e-mail sending is enabled) [$NTFY_SMTP_SENDER_USER]
   --smtp-server-addr-prefix value, --smtp_server_addr_prefix value                                    SMTP email address prefix for topics to prevent spam (e.g. 'ntfy-') [$NTFY_SMTP_SERVER_ADDR_PREFIX]
   --smtp-server-domain value, --smtp_server_domain value                                              SMTP domain for incoming e-mail, e.g. ntfy.sh [$NTFY_SMTP_SERVER_DOMAIN]
   --smtp-server-listen value, --smtp_server_listen value                                              SMTP server address (ip:port) for incoming emails, e.g. :25 [$NTFY_SMTP_SERVER_LISTEN]
   --trace                                                                                             enable tracing (very verbose, be careful) (default: false) [$NTFY_TRACE]
   --upstream-base-url value, --upstream_base_url value                                                forward poll request to an upstream server, this is needed for iOS push notifications for self-hosted servers [$NTFY_UPSTREAM_BASE_URL]
   --visitor-attachment-daily-bandwidth-limit value, --visitor_attachment_daily_bandwidth_limit value  total daily attachment download/upload bandwidth limit per visitor (default: "500M") [$NTFY_VISITOR_ATTACHMENT_DAILY_BANDWIDTH_LIMIT]
   --visitor-attachment-total-size-limit value, --visitor_attachment_total_size_limit value            total storage limit used for attachments per visitor (default: "100M") [$NTFY_VISITOR_ATTACHMENT_TOTAL_SIZE_LIMIT]
   --visitor-email-limit-burst value, --visitor_email_limit_burst value                                initial limit of e-mails per visitor (default: 16) [$NTFY_VISITOR_EMAIL_LIMIT_BURST]
   --visitor-email-limit-replenish value, --visitor_email_limit_replenish value                        interval at which burst limit is replenished (one per x) (default: 1h0m0s) [$NTFY_VISITOR_EMAIL_LIMIT_REPLENISH]
   --visitor-request-limit-burst value, --visitor_request_limit_burst value                            initial limit of requests per visitor (default: 60) [$NTFY_VISITOR_REQUEST_LIMIT_BURST]
   --visitor-request-limit-exempt-hosts value, --visitor_request_limit_exempt_hosts value              hostnames and/or IP addresses of hosts that will be exempt from the visitor request limit [$NTFY_VISITOR_REQUEST_LIMIT_EXEMPT_HOSTS]
   --visitor-request-limit-replenish value, --visitor_request_limit_replenish value                    interval at which burst limit is replenished (one per x) (default: 5s) [$NTFY_VISITOR_REQUEST_LIMIT_REPLENISH]
   --visitor-subscription-limit value, --visitor_subscription_limit value                              number of subscriptions per visitor (default: 30) [$NTFY_VISITOR_SUBSCRIPTION_LIMIT]
   --web-root value, --web_root value                                                                  sets web root to landing page (home), web app (app) or disabled (disable) (default: "app") [$NTFY_WEB_ROOT]