Installazione come server web per Linux
Questa guida descrive come eseguire CODESYS 4 come server su Linux.
Compatibilità
CODESYS 4 Al momento, il supporto ufficiale per Linux è limitato a Debian. È possibile che il pacchetto possa essere reso compatibile anche con altre distribuzioni basate su Debian, come Ubuntu, Kubuntu, ecc. Tuttavia, il supporto in tal caso sarebbe limitato.
Osservazioni preliminari
Nozioni fondamentali di amministrazione di sistemi Linux
Gestione degli utenti su Linux (PAM, LDAP, IPA, ecc.)
Gestione dei pacchetti su Debian
Conoscenza della gestione dei certificati TLS e, se possibile, della relativa infrastruttura.
Possibile conoscenza di Docker, nginx e altre tecnologie server.
HTTPS/TLS
CODESYS 4 utilizza API del browser che sono disponibili solo in un contesto sicuro. Questo è sempre il caso quando l'accesso avviene tramite localhost.
Non appena vuoi fare CODESYS 4 Sebbene il server sia accessibile ad altri computer della rete, è assolutamente necessario che la comunicazione avvenga tramite HTTPS, altrimenti l'applicazione non funzionerà correttamente.
Perché CODESYS 4 Il sistema non supporta ancora la comunicazione tramite HTTPS; per farlo, è necessario configurare un proxy upstream. Per ulteriori informazioni, leggere l'intera sezione. Configurazione di un proxy inverso TLS a monte accuratamente.
Tempo di esecuzione e gateway
I pacchetti Linux da CODESYS 4 attualmente non includono un CODESYS Gateway o un CODESYS Tempo di esecuzione.
Puoi trovare i download corrispondenti in CODESYS Store.
Assicurati di configurare le impostazioni di comunicazione (gateway) nel tuo progetto in modo da poter accedere al controller dal server.
Gli utenti che lavorano sul server possono accedervi solo con CODESYS Gateway e controller raggiungibili dal server. Assicurarsi che il server abbia accesso ai gateway richiesti oppure rendere disponibile un gateway locale direttamente sul server.
Preparazione: Creazione degli account utente
Per impostazione predefinita, la gestione utente dell' CODESYS 4 Il server si basa sulla gestione degli utenti del sistema Debian. Ogni normale utente Linux che è membro del codesys-4 il gruppo può accedere al CODESYS 4 server per impostazione predefinita. Tuttavia, è possibile avviare il server anche con l'opzione --login-groups=first,second,third per specificare uno o più altri gruppi che dovrebbero essere autorizzati ad accedere in alternativa.
Crea il
codesys-4gruppo.Questa operazione è necessaria solo una volta e viene eseguita automaticamente durante l'installazione del pacchetto Debian.
Se desideri utilizzare un gruppo diverso, specifica qui il tuo gruppo.
sudo addgroup codesys-4
Crea il nuovo utente
User1se non esiste già.(La richiesta di informazioni sull'utente come
FullName,Room Number(ecc. possono essere semplicemente omessi lasciandoli vuoti.)sudo adduser User1
Aggiungere
User1per ilcodesys-4gruppo. Assegna l'utente a un gruppo diverso se stai utilizzando un gruppo personalizzato.(Questo concede all'utente il permesso di accedere al server.)
sudo adduser User1 codesys-4
È possibile creare un numero qualsiasi di utenti. Tutti gli utenti che possono accedere utilizzando una password e sono membri del codesys-4 il gruppo può accedere a CODESYS 4.
Funzionamento come server tramite systemd
CODESYS 4 poiché un server deve essere eseguito con un utente di sistema dedicato.
Preparazione
CODESYS 4 deve essere installato sul server web. Per fare ciò, installare CODESYS 4 secondo la guida nel capitolo Installazione come applicazione desktop per Linux (fino alla sezione "Installazione di un pacchetto Debian" inclusa).
Creare un utente di sistema dedicato a scopo di test.
> sudo useradd --system --create-home c4-server
Nella directory
/etc/systemd/system/codesys-4.service, configurare ilService Unitfile persystemd[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
Avvia il servizio tramite
systemd.$> sudo systemctl start codesys-4
Il servizio sarà disponibile tramite HTTP su
localhostsulla porta 8080.
Funzionamento come server tramite Docker
Non è un'immagine Docker standard.
CODESYS 4 non è attualmente distribuito come immagine Docker. Di conseguenza, non esiste un'immagine Docker ufficiale destinata all'uso produttivo di CODESYS 4.
È tuttavia possibile creare una propria immagine Docker. I passaggi per farlo sono descritti più avanti in questa sezione.
Conoscenze pregresse e supporto
Per configurare correttamente questo caso d'uso, è assolutamente necessaria una conoscenza di base di Docker. Non è possibile fornire supporto per l'utilizzo di base di 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"]
Per creare l'immagine, è necessario prima scaricare il pacchetto Debian per CODESYS 4 e salvalo nel output/ sottocartella in cui si trova il Dockerfile. Quindi puoi creare l'immagine come di consueto utilizzando il docker buildx build comando.
Quando si avvia l'immagine in un container, tenere presente che solo gli utenti che esistono nel container e sono membri del codesys-4 il gruppo può accedere al server (confronta con il capitolo Preparazione: Creazione degli account utente).
Gli utenti devono avere accesso a meccanismi adeguati all'interno del container, ad esempio PAM. Le directory home devono essere montate, per quanto possibile, come volumi persistenti nel container. Le definizioni di gruppo devianti tramite il --login-groups L'opzione può essere specificata nel Dockerfile come argomento nella definizione di ENTRYPOINT oppure può essere passata come argomento all'avvio del container.
A scopo di test, è possibile sincronizzare gli utenti esistenti sull'host nel container subito dopo l'avvio, come mostrato in docker-test-example.sh sceneggiatura:
(Naturalmente, sarà necessario adattare lo script alle proprie esigenze specifiche, come ad esempio gli identificatori dei tag e il proprio registro 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.Preposizionamento di un proxy inverso TLS
CODESYS 4 utilizza API del browser che sono disponibili solo in un contesto sicuro. Questo è sempre il caso quando l'accesso avviene tramite localhost. Non appena CODESYS 4 Poiché un server è accessibile da altri computer nella rete, è necessario configurare una crittografia TLS, il cui certificato server sia considerato attendibile dai browser utilizzati.
CODESYS 4 al momento non implementa ancora la crittografia TLS. Quando CODESYS 4 se eseguito dietro un proxy del portale, può mantenere la crittografia TLS. Altrimenti, un proxy inverso come nginx può essere facilmente preposizionato in anticipo, il che manterrà la crittografia TLS. In particolare, il proxy_set_header E proxy_cache_bypass Le direttive sono necessarie affinché tutto funzioni correttamente (incluso WebSocket).
Certificati SSL
Per questo caso d'uso, è assolutamente necessario un certificato SSL valido oppure un certificato SSL autofirmato classificato come attendibile all'interno della propria organizzazione.
Consultate il vostro amministratore IT e non tentate di classificare i vostri certificati come attendibili senza averne prima avuto conferma.
Se desideri comunque rilasciare certificati a scopo di test e sai cosa stai facendo, puoi seguire la guida nella sezione Utilizzo di certificati TLS a scopo di test Questi certificati non devono mai essere utilizzati in produzione.
Nginx come proxy inverso
L'esempio seguente mostra una configurazione di nginx come proxy inverso per mantenere la crittografia TLS per CODESYS 4. Puoi salvare il seguente file in /etc/nginx/sites-available/codesys-4. Devi anche adattare i percorsi sotto ssl_certificate E ssl_certificate_key alle posizioni effettive dei tuoi certificati. Dopodiché, puoi utilizzare symlink per abilitare la configurazione in /etc/nginx/sites-enabled/ e riavviare 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;
}Certificati TLS a scopo di test
Avviso di sicurezza
ATTENZIONE: L'emissione e l'utilizzo di certificati propri possono comportare un rischio significativo per la sicurezza. Eseguire i seguenti passaggi solo se si dispone dell'autorizzazione dell'amministratore IT. Non tentare di aggirare criteri di gruppo o altre misure di sicurezza esistenti per eseguire questi passaggi.
Per un utilizzo a livello produttivo, si raccomanda vivamente di utilizzare certificati rilasciati da un'autorità di certificazione (CA) ufficiale riconosciuta dai browser, oppure, in alternativa, certificati riconosciuti all'interno dell'infrastruttura aziendale. In caso di dubbi, consultare il reparto IT.
Assicurati assolutamente di salvare i file della chiave privata example.key e in particolare exampleca.key devono essere protetti in modo sicuro e non accessibili a nessun altro. Chiunque acceda a questi file può utilizzarli per falsificare un numero qualsiasi di certificati e quindi lanciare un attacco man-in-the-middle contro di te o la tua organizzazione.
È possibile utilizzare il openssl comando per generare certificati a scopo di test come mostrato di seguito. Prima di ciò, nel example_cert.ext file, dovrai modificare i nomi host per i quali il certificato dovrebbe essere valido. Dovresti anche adattare il --subj parametri nei comandi in base al tuo caso d'uso specifico.
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
Compatibilità
Con una shell basata su Cygwin, ad esempio Git bash, openssl req Il comando potrebbe non riuscire. Si tratta di un problema noto di OpenSSL in relazione a Cygwin. Per ulteriori informazioni, consultare quanto segue: https://github.com/openssl/openssl/issues/8795.
Il problema non dovrebbe verificarsi quando si esegue OpenSSL in una shell Linux autentica (chiamata anche WSL) o tramite la riga di comando di CMD o PowerShell.
Il certificato radice exampleca.crt deve quindi essere registrato come attendibile nei rispettivi browser. Il certificato effettivo codesys-4-development-certificate.crt e la rispettiva chiave privata example.key deve essere installato sul server e referenziato nella configurazione del server. Ad esempio, nginx può essere utilizzato a questo scopo (vedere la sezione Preposizionamento di un proxy inverso TLS.
Ricorda di rimuovere il exampleca.crt certificato dall'elenco dei certificati attendibili nei tuoi browser dopo la fase di test.