Instalación como servidor web para Linux
Esta guía describe cómo ejecutar CODESYS 4 como servidor en Linux.
Compatibilidad
CODESYS 4 Actualmente, el soporte oficial para Linux se limita a Debian. Es posible que el paquete también pueda ejecutarse en otras distribuciones basadas en Debian, como Ubuntu, Kubuntu, etc. Sin embargo, el soporte para estas distribuciones es limitado.
Observaciones preliminares
Fundamentos de la administración de sistemas Linux
Gestión de usuarios en Linux (PAM, LDAP, IPA, etc.)
Gestión de paquetes en Debian
Conocimiento de la gestión de certificados TLS y, si es posible, de la infraestructura correspondiente.
Posiblemente se requiera conocimiento de Docker, nginx y otras tecnologías de servidor.
HTTPS/TLS
CODESYS 4 utiliza API del navegador que solo están disponibles en un contexto seguro. Este es siempre el caso cuando el acceso es a través de localhost.
Tan pronto como quieras hacerlo CODESYS 4 Sin embargo, al ser un servidor accesible a otros ordenadores de la red, es absolutamente necesario que la comunicación se realice a través de HTTPS; de lo contrario, la aplicación no funcionará correctamente.
Porque CODESYS 4 El servidor en sí aún no admite la comunicación a través de HTTPS; deberá configurar un proxy ascendente para ello. Para obtener más información, lea la sección completa. Configuración de un proxy inverso TLS ascendente con cuidado.
Entorno de ejecución y puerta de enlace
Los paquetes de Linux de CODESYS 4 actualmente no incluyen un CODESYS Puerta de enlace o una CODESYS Tiempo de ejecución.
Puedes encontrar las descargas correspondientes en el CODESYS Store.
Asegúrese de configurar los ajustes de comunicación (pasarela) en su proyecto para poder acceder al controlador desde el servidor.
Los usuarios que trabajan en el servidor solo pueden acceder a él con CODESYS Puertas de enlace y controladores a los que puede acceder el servidor. Asegúrese de que el servidor tenga acceso a las puertas de enlace necesarias o habilite una puerta de enlace local directamente en el servidor.
Preparación: Creación de cuentas de usuario
Por defecto, la gestión de usuarios de la CODESYS 4 El servidor se basa en la gestión de usuarios del sistema Debian. Todo usuario ordinario de Linux que sea miembro del codesys-4 El grupo puede iniciar sesión en el CODESYS 4 servidor por defecto. Sin embargo, también puede iniciar el servidor con la opción --login-groups=first,second,third para especificar uno o más grupos que deberían poder iniciar sesión en su lugar.
Crear el
codesys-4grupo.Esto solo es necesario una vez y se realiza automáticamente durante la instalación del paquete Debian.
Indique aquí su propio grupo si desea utilizar un grupo diferente.
sudo addgroup codesys-4
Crear el nuevo usuario
User1si aún no existe.(La solicitud de información del usuario como
FullName,Room Number, etc., simplemente se pueden omitir dejándolos en blanco.)sudo adduser User1
Agregar
User1haciacodesys-4grupo. Asigne al usuario a un grupo diferente si está utilizando su propio grupo.(Esto otorga a ese usuario permiso para iniciar sesión en el servidor).
sudo adduser User1 codesys-4
Puedes crear cualquier número de usuarios. Todos los usuarios que puedan iniciar sesión usando una contraseña y sean miembros de la codesys-4 El grupo puede iniciar sesión en CODESYS 4.
Funcionamiento como servidor a través de systemd
CODESYS 4 ya que un servidor debe ejecutarse bajo un usuario de sistema dedicado.
Preparación
CODESYS 4 debe instalarse en el servidor web. Para ello, instale CODESYS 4 Según la guía del capítulo Instalación como aplicación de escritorio para Linux (hasta la sección "Instalación de un paquete Debian" inclusive).
Cree un usuario de sistema específico para fines de prueba.
> sudo useradd --system --create-home c4-server
En el directorio
/etc/systemd/system/codesys-4.service, configurar elService Unitarchivo parasystemd[Unit] Description=CODESYS 4 Server [Service] Type=exec WorkingDirectory=/opt/codesys-4/ ExecStart=/opt/codesys-4/c4-server --port 8080 Restart=always # Restart service after 10 seconds if the dotnet service crashes: RestartSec=10 KillSignal=SIGINT SyslogIdentifier=codesys-4-server User=c4-server Environment=ASPNETCORE_ENVIRONMENT=Production Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false [Install] WantedBy=multi-user.target
Inicie el servicio a través de
systemd.$> sudo systemctl start codesys-4
El servicio estará disponible a través de HTTP en
localhosten el puerto 8080.
Funcionamiento como servidor mediante Docker
No es una imagen Docker estándar
CODESYS 4 Actualmente no se distribuye como una imagen de Docker. Como resultado, no existe una imagen oficial de Docker destinada al uso productivo de CODESYS 4.
Sin embargo, puedes crear tu propia imagen de Docker. Los pasos para ello se describen más adelante en esta sección.
Conocimientos previos y apoyo
Para configurar correctamente este caso de uso, es imprescindible tener conocimientos básicos de Docker. No se ofrece soporte para el uso básico de Docker.
# Official ASP.NET 8.0 runtime base image FROM mcr.microsoft.com/dotnet/aspnet:8.0 WORKDIR /opt/codesys-4 # The default port is 8080 EXPOSE 8080 # We have to be root to install the package, switch back to app after USER root # Install the Debian package for CODESYS 4. # We set ACCEPT_CODESYS_EULA=true to skip the interactive prompt to accept the EULA during package installation. # Building and executing this Dockerfile therefore means you accept the terms and condition of the CODESYS Engineering EULA! RUN --mount=type=bind,source=output/,target=/tmp/output/ <<EOF ACCEPT_CODESYS_EULA=true dpkg -i /tmp/output/codesys-4*.deb EOF # The server should run with the unprivileged system user "app", see # https://learn.microsoft.com/en-us/dotnet/core/compatibility/containers/8.0/app-user # For security reasons, c4-server will refuse to start as root. USER app:app ENTRYPOINT ["/opt/codesys-4/c4-server"]
Para construir la imagen, primero debe descargar el paquete Debian para CODESYS 4 y guárdalo en el output/ subcarpeta donde se encuentra el Dockerfile. Luego puede construir la imagen como de costumbre usando el comando docker buildx build.
Al iniciar la imagen en un contenedor, tenga en cuenta que solo los usuarios que existen en el contenedor y son miembros del mismo podrán acceder. codesys-4 El grupo puede iniciar sesión en el servidor (comparar con el capítulo Preparación: Creación de cuentas de usuario).
Los usuarios deben tener acceso a mecanismos adecuados dentro del contenedor, por ejemplo PAM. Los directorios de inicio deben montarse, en la medida de lo posible, como volúmenes persistentes en el contenedor. Las definiciones de grupo que se desvíen a través del contenedor --login-groups Esta opción puede especificarse en el Dockerfile como un argumento en la definición de ENTRYPOINT o pasarse como un argumento cuando se inicia el contenedor.
Para fines de prueba, puede sincronizar los usuarios existentes en el host en el contenedor inmediatamente después de iniciarlo, como se muestra en el docker-test-example.sh guion:
(Por supuesto, deberá adaptar el script a sus condiciones específicas, como sus identificadores de etiquetas y su propio registro de Docker).
# This script is used to start our CODESYS 4 docker containers in our
# development and test environments (RasPi, WSL, Linux VM).
# It's not regarded as safe for production use!
# The name of our container
CONTAINER=codesys-4
# The repository to fetch the image from
URL="dockerhost.example.com:1234/codesys-images/codesys-4:develop"
# Stop and clean up any running container.
if docker inspect "$CONTAINER" > /dev/null 2>&1; then
echo Trying to clean up
docker stop "$CONTAINER"
docker rm "$CONTAINER"
fi
# stop and rm may fail when the container does not exist,
# but from here on, we want to abort on first error
set -e
echo Downloading "$URL"...
docker pull "$URL"
echo starting image...
# Starting the docker image.
# We mount the /home folder. We listen on port 8080.
# The option "--add-host host.docker.internal:host-gateway" allows us to access
# a CODESYS gateway running on the host machine via the hostname
# "host.docker.internal" from within the container.
docker run --restart=unless-stopped --detach \
--volume /home:/home \
-p127.0.0.1:8080:8080 \
-e CBE_PORT=8080 \
--add-host host.docker.internal:host-gateway \
--name "$CONTAINER" \
"$URL"
# output the version and build info, with some newlines, so it's easier readable.
echo -e \\n CODESYS 4 image build info: $(docker exec codesys-4 cat /opt/codesys-4/dist/version.json) \\n
# Ensure we have a home directory the app user can use, to write the C4 log files.
# The base image already contains /home/app, but it's shadowed by mounting our
# /home into the container, so we need to create the folder if it doesn't exist.
# Strictly speaking, this is only necessary once on a given host (because /home
# has been mounted from the host), but if we run it always, we can be sure that
# this script will also work on fresh machines.
docker exec --user 0 "$CONTAINER" bash -c "mkdir -v -p /home/app ; chown -v app:app /home/app ; chmod -v og-rwx /home/app"
# Synchronize the actual users into the container. We use a very hackish approach
# here, not recommended for production use, it just works for the dev environment.
# WARNING: Synchronizing will only work when:
# 1) The users do not yet exist within the container
# 2) The numeric user and group IDs are not yet occupied within the container.
# Also, it's recommended to configure sudo so it caches the password using
# timestamp-timeout, or even NOPASSWD if you want to take the risk.
# Only the groups codesys-4 and the user personal group will be synchronized.
echo synchronizing group codesys-4
getent group codesys-4| docker exec --user 0 -i "$CONTAINER" /bin/sh -c "cat >>/etc/group"
sudo getent gshadow codesys-4| docker exec --user 0 -i "$CONTAINER" /bin/sh -c "cat >>/etc/gshadow"
# get all users in group codesys-4
C4_USERS=$(getent group codesys-4| awk -F':' '{print $4}' | tr ',' ' ')
for CURRENT in $C4_USERS ; do
echo synchronizing user $CURRENT
getent passwd $CURRENT | docker exec --user 0 -i "$CONTAINER" /bin/sh -c "cat >>/etc/passwd"
sudo getent shadow $CURRENT | docker exec --user 0 -i "$CONTAINER" /bin/sh -c "cat >>/etc/shadow"
# we also need to synchronize the user specific group
getent group $CURRENT | docker exec --user 0 -i "$CONTAINER" /bin/sh -c "cat >>/etc/group"
sudo getent gshadow $CURRENT | docker exec --user 0 -i "$CONTAINER" /bin/sh -c "cat >>/etc/gshadow"
done
echo finished.Preposicionamiento de un proxy inverso TLS
CODESYS 4 utiliza API del navegador que solo están disponibles en un contexto seguro. Este es siempre el caso cuando el acceso es a través de localhost. Tan pronto como CODESYS 4 Dado que un servidor es accesible desde otros ordenadores de la red, es necesario configurar un cifrado TLS, cuyo certificado de servidor sea de confianza para los navegadores utilizados.
CODESYS 4 actualmente no implementa el cifrado TLS. CODESYS 4 se ejecuta detrás de un proxy de portal, puede mantener el cifrado TLS. De lo contrario, un proxy inverso como nginx se puede preposicionar fácilmente de antemano, lo que mantendrá el cifrado TLS. En particular, el proxy_set_header y proxy_cache_bypass Las directivas son necesarias para que todo funcione correctamente (incluido WebSocket).
Certificados SSL
Para este caso de uso, es imprescindible contar con un certificado SSL válido o un certificado SSL autofirmado que esté clasificado como de confianza dentro de su organización.
Consulte con su administrador de TI y no intente clasificar sus propios certificados como de confianza sin conocimiento previo.
Si aún desea emitir certificados para fines de prueba y sabe lo que está haciendo, puede seguir la guía en la sección Uso de certificados TLS con fines de prueba Estos certificados nunca deben utilizarse en producción.
Nginx como proxy inverso
El siguiente ejemplo muestra una configuración de nginx como proxy inverso para mantener el cifrado TLS para CODESYS 4. Puedes guardar el siguiente archivo en /etc/nginx/sites-available/codesys-4 También necesitas adaptar las rutas en ssl_certificate y ssl_certificate_key a las ubicaciones reales de sus certificados. Después de eso, puede usar symlink para habilitar la configuración en /etc/nginx/sites-enabled/ y reiniciar nginx.
# See https://docs.microsoft.com/en-us/troubleshoot/developer/webapps/aspnetcore/practice-troubleshoot-linux/2-2-install-nginx-configure-it-reverse-proxy
# for more information.
server {
listen 443 ssl;
listen [::]:443 ssl;
ssl_certificate /etc/ssl/certs/codesys-4-certificate.crt;
ssl_certificate_key /etc/ssl/private/codesys-4.key;
#server_name _;
server_tokens off; # see https://nginx.org/en/docs/http/ngx_http_core_module.html#server_tokens
location / {
rewrite ^/$ /index.html last;
proxy_pass http://127.0.0.1:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection keep-alive;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
#hsts header
add_header Strict-Transport-Security "max-age=31536000" always;
}
}
# Redirect unencrypted http access to encrypted https access.
server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
server_name _;
return 301 https://$host$request_uri;
}Certificados TLS para fines de prueba
Aviso de seguridad
ADVERTENCIA: Emitir y confiar en sus propios certificados puede suponer un riesgo de seguridad significativo. Realice los siguientes pasos únicamente si cuenta con la autorización de su administrador de TI. No intente eludir las directivas de grupo ni otras medidas de seguridad existentes para llevar a cabo estos pasos.
Para un uso productivo, se recomienda encarecidamente utilizar certificados de una autoridad de certificación (CA) oficial reconocida por los navegadores o, alternativamente, certificados reconocidos dentro de la infraestructura de su empresa. En caso de duda, consulte con su departamento de TI.
Asegúrese de guardar los archivos de clave privada. example.key y en particular exampleca.key Almacenados de forma segura y sin acceso para terceros. Cualquiera que acceda a estos archivos puede utilizarlos para falsificar certificados y, de este modo, lanzar un ataque de intermediario contra usted o su organización.
Puedes usar el openssl comando para generar certificados para fines de prueba como se muestra a continuación. Antes de eso, en el example_cert.ext archivo, deberá editar los nombres de host para los que el certificado debe ser válido. También debe adaptar el --subj Parámetros en los comandos según su caso de uso específico.
authorityKeyIdentifier=keyid,issuer basicConstraints=CA:FALSE keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment extendedKeyUsage=serverAuth subjectAltName = @alt_names [alt_names] DNS.1=localhost # adjust these to your needs DNS.2=first.host.example.com DNS.3=other.host.example.com
# Generate development/testing certificates for CODESYS 4. # Add the hostnames to example_cert.ext with your favourite text editor. # Creating the CA: openssl genrsa -out exampleca.key 2048 openssl req -new -x509 -days 365 -key exampleca.key -subj "/C=ZZ/ST=Example Kingdom/L=Example City/O=Example Organization/CN=Example Test CA" -out exampleca.crt # Creating the Certificate: openssl genrsa -out example.key 2048 openssl req -new -nodes -out example.csr -key example.key -subj "/C=ZZ/ST=Example Kingdom/L=Example City/O=Example Organization/CN=Example Test Server" openssl x509 -req -days 365 -in example.csr -CA exampleca.crt -CAkey exampleca.key -out codesys-4-development-certificate.crt -extfile example_cert.ext -CAcreateserial
Importante
Compatibilidad
Con un intérprete de comandos basado en Cygwin, por ejemplo Git bash, el openssl req El comando podría fallar. Este es un problema conocido de OpenSSL en relación con Cygwin. Para obtener más información, consulte lo siguiente: https://github.com/openssl/openssl/issues/8795.
Este problema no debería producirse al ejecutar OpenSSL en una consola Linux auténtica (también llamada WSL) o a través de la línea de comandos de CMD o PowerShell.
El certificado raíz exampleca.crt Luego, debe registrarse como de confianza en los navegadores correspondientes. El certificado real codesys-4-development-certificate.crt y la clave privada correspondiente example.key Debe estar instalado en el servidor y referenciado en la configuración del servidor. Por ejemplo, se puede utilizar nginx para este propósito (consulte la sección Preposicionamiento de un proxy inverso TLS.
Recuerda quitar el exampleca.crt El certificado de la lista de certificados de confianza en sus navegadores después de la fase de prueba.