Note di rilascio#

Rilasci NethServer 8

Cambiamenti principali del 2024-02-13#

Versione stabile

Le nuove funzionalità introdotte da questa release sono:

  • Abbonamento – I piani di abbonamento Nethesis Enterprise e Community Subscription sono ora disponibili per NS8. Maggiori dettagli nella pagina Subscription.

  • Portale di gestione degli utenti – I membri del gruppo Domain Admins possono ora creare, modificare ed eliminare gli account utente dal Portale di gestione utente. La schermata di login ora visualizza il nome del dominio dell’utente per distinguere a quale dominio utente si accede.

  • Salta la verifica del certificato nelle route HTTP – quando viene creata o modificata una rotta HTTP nella pagina delle rotte HTTP, l’opzione Salta la verifica del certificato può essere abilitata su una rete fidata nel caso in cui il server all’URL di destinazione non abbia un certificato TLS valido.

  • Cockpit rimosso dall’immagine pre-built – Cockpit non è necessario per NS8, quindi non è più disponibile nell’immagine pre-built di NS8. Se lo si desidera, può essere installato e abilitato manualmente con i seguenti comandi:

    dnf install -y cockpit
    systemctl enable --now cockpit.socket
    

    La configurazione predefinita di Cockpit proibisce l’accesso a root: accedere con un utente membro del gruppo wheel, quindi attivare la modalità «accesso amministrativo».

Problemi noti:

  • Core upgrade congela la pagina Software Center – Il bug 6778 è stato fissato nella versione core 2.2.6. Se l’aggiornamento da RC1 inizia dalla versione core 2.2.5 o inferiore, quando la barra di avanzamento dell’attività si blocca, ricaricare la pagina web con CTRL + SHIFT + R o una procedura equivalente. La ricarica della pagina non ha alcun impatto sull’aggiornamento in corso. Nota: il download dell’aggiornamento può essere lento; evitare di interrompere o riavviare fino al completamento.

Principali cambiamenti del 2023-11-21#

Release Candidate 1

Nuove funzionalità introdotte dalla RC1:

  • Policy delle password – Aggiunta una nuova opzione di configurazione nella pagina Domini e utenti. È possibile modificare la complessità delle password e le politiche di scadenza dei domini Samba e OpenLDAP. Le installazioni Beta 2 con i domini OpenLDAP richiedono di eseguire una procedura manuale per abilitare le password policy. La procedura di aggiornamento è dettagliata nelle note successive. Vedi anche Password policy.

  • Portale di gestione degli utenti – Gli utenti di un dominio possono ora accedere a una pagina web per modificare la propria password. Il portale dell’utente è disponibile all’indirizzo https://IP_OR_FQDN/users-admin/DOMAIN_NAME/; un link completo viene visualizzato nella pagina Domini e utenti, sotto le impostazioni di configurazione del dominio. Le installazioni Beta 2 richiedono di eseguire una procedura manuale per abilitare il portale utente. Vedere la procedura di aggiornamento per Samba e OpenLDAP nelle note successive, e la pagina: user-management-portal-section .

  • Repository backup – Oltre ai protocolli cloud esistenti, è ora più facile inviare i backup ad alcuni dispositivi locali. Un repository di backup può ora essere creato in una share Windows o in uno Storage locale, come un disco attaccato a un nodo di cluster. Vedi Backup e ripristino per maggiori informazioni.

  • Raccolta mail da altri serverImapsync è una nuova applicazione avanzata progettata per recuperare i messaggi e-mail da server IMAP remoti a intervalli programmati e sincronizzare interi account IMAP.

  • Lista mirror per i nodi Rocky Linux – Se Rocky Linux è la distribuzione OS usata in un nodo, la configurazione predefinita DNF viene sovrascritta e i mirror vengono gestiti da mirrorlist.nethserver.org. Nelle future versioni i pacchetti RPM di Rocky Linux saranno ospitati da mirror specifici di NethServer.

L’aggiornamento delle installazioni Beta 2 esistenti può essere avviato dalla pagina Software center come al solito. Dopo che i componenti principali sono aggiornati, eseguire le seguenti procedure manuali per completare l’aggiornamento.

  • Procedura di aggiornamento del core – Per aggiornare le installazioni Beta 2 eseguire il seguente comando sul nodo leader. Definisce il nuovo ruolo di autorizzazione tunadm, disponibile su nuove installazioni dalla versione core 2.1.0:

    redis-cli --raw hvals cluster/module_node | sort -n | uniq | xargs -I NODE_ID -- redis-cli SADD node/NODE_ID/roles/tunadm add-tun remove-tun add-public-service remove-public-service add-custom-zone remove-custom-zone
    

    Per ogni nodo del cluster, abilitare il servizio WebDAV locale per i backup:

    systemctl enable --now rclone-webdav.service
    

    Infine, solo per i nodi Rocky Linux, abilitare i repository di default NethServer:

    cp -v /etc/nethserver/nethserver.repo /etc/yum.repos.d/nethserver.repo
    dnf config-manager --save --set-disabled appstream baseos extras
    
  • Procedura aggiornamento Samba – Per aggiornare le installazioni Beta 2 eseguire la procedura seguente per ogni istanza dell’account provider Samba. L’elenco delle istanze può essere ottenuto dalla pagina Domini e utenti, sotto le impostazioni di configurazione del dominio; annotare per ogni provider:

    • L’ID del modulo (stringa), per esempio samba1

    • L’ID del nodo (numero), per esempio 1

    • il numero di una porta TCP disponibile, generato eseguendo sul nodo leader questo comando:

      node_id=1
      echo $((`redis-cli --raw INCR node/${node_id}/tcp_ports_sequence` - 1))
      

      Nell’esempio sopra è necessario assegnare a node_id il corretto ID del nodo (numero). Supponiamo che il comando stampi il seguente numero di porta:

      20013
      

    Con le annotazioni recuperate precedentemente, eseguire i seguenti passaggi per ogni provider:

    1. Accedere al nodo del cluster in cui viene eseguita l’istanza del provider.

    2. Applicare la configurazione della porta TCP e avviare il servizio del portale utente:

      runagent -m samba1 python3 - 20013 <<'EOF'
      import agent, os, sys
      user_portal_port = sys.argv[1]
      agent.assert_exp(int(user_portal_port) > 0, "ERROR: Bad TCP port argument")
      agent.assert_exp("IPADDRESS" in os.environ, "ERROR: Samba is not configured")
      agent.assert_exp(not "TCP_PORT" in os.environ, "ERROR: TCP_PORT is already set")
      os.environ["TCP_PORT"] = user_portal_port
      agent.set_env("TCP_PORT", user_portal_port)
      os.execl("../actions/configure-module/80start_amld", "80start_amld")
      EOF
      
  • Procedura di aggiornamento OpenLDAP – Per aggiornare le installazioni Beta 2 eseguire la procedura seguente per ogni istanza dell’account provider OpenLDAP. L’elenco delle istanze può essere ottenuto dalla pagina Domini e utenti, sotto le impostazioni di configurazione del dominio; annotare per ogni provider:

    • L’ID del modulo (stringa), per esempio openldap1

    • L’ID del nodo (numero), per esempio 1

    • il numero di una porta TCP disponibile, generato eseguendo sul nodo leader questo comando:

      node_id=1
      echo $((`redis-cli --raw INCR node/${node_id}/tcp_ports_sequence` - 1))
      

      Nell’esempio sopra è necessario assegnare a node_id il corretto ID del nodo (numero). Supponiamo che il comando stampi il seguente numero di porta:

      20014
      

    Con le annotazioni recuperate precedentemente, eseguire i seguenti passaggi per ogni provider:

    1. Accedere al nodo del cluster in cui viene eseguita l’istanza del provider.

    2. Applicare la configurazione della porta TCP e avviare il servizio del portale utente:

      runagent -m openldap1 python3 - 20014 <<'EOF'
      import agent, os, sys
      user_portal_port = sys.argv[1]
      agent.assert_exp(int(user_portal_port) > 0, "ERROR: Bad TCP port argument")
      agent.assert_exp("LDAP_IPADDR" in os.environ, "ERROR: OpenLDAP is not configured")
      agent.assert_exp(not "," in os.environ["TCP_PORTS"], "ERROR: unexpected TCP_PORTS value")
      os.environ["TCP_PORTS"] = f'{os.environ["TCP_PORT"]},{user_portal_port}'
      agent.set_env("TCP_PORTS", os.environ["TCP_PORTS"])
      os.execl("../actions/configure-module/80start_amld", "80start_amld")
      EOF
      

    Dopo aver ripetuto i passaggi sopra per ogni nodo del cluster, eseguire i seguenti comandi in un’istanza a scelta (l’esempio è per openldap1):

    runagent -m openldap1 podman exec -i openldap ash -c 'envsubst | ldapmodify -c ' <<'EOF'
    dn: olcDatabase={2}mdb,cn=config
    changetype: modify
    delete: olcAccess
    -
    add: olcAccess
    olcAccess: to attrs=userPassword by dn.base="
     gidNumber=101+uidNumber=100,cn=peercred,cn=external,cn=aut
     h" write by set="[cn=domain admins,ou=Groups,${LDAP_SUFFIX}
     ]/memberUid & user/uid" write by self write by * auth
    olcAccess: to * by dn.base="gidNumber=101+uidNumber=100,
     cn=peercred,cn=external,cn=auth" manage by set="[cn=do
     main admins,ou=Groups,${LDAP_SUFFIX}
     ]/memberUid & user/uid" write by * read
    
    dn: olcOverlay={1}ppolicy,olcDatabase={2}mdb,cn=config
    changetype: modify
    replace: olcPPolicyCheckModule
    olcPPolicyCheckModule: ppcheck.so
    
    dn: cn=default,ou=PPolicy,${LDAP_SUFFIX}
    changetype: modify
    add: objectClass
    objectClass: pwdPolicyChecker
    
    dn: cn=default,ou=PPolicy,${LDAP_SUFFIX}
    changetype: modify
    replace: pwdCheckQuality
    pwdCheckQuality: 2
    -
    replace: pwdMinAge
    pwdMinAge: 0
    -
    replace: pwdMaxAge
    pwdMaxAge: 15552000
    -
    replace: pwdMinLength
    pwdMinLength: 8
    -
    replace: pwdInHistory
    pwdInHistory: 12
    -
    replace: pwdLockout
    pwdLockout: FALSE
    -
    replace: pwdUseCheckModule
    pwdUseCheckModule: TRUE
    -
    replace: pwdCheckModuleArg
    pwdCheckModuleArg: default
    -
    replace: pwdExpireWarning
    pwdExpireWarning: 0
    EOF
    
    runagent -m openldap1 systemctl --user restart openldap
    
  • Procedura di aggiornamento Mattermost – l’aggiornamento di Mattermost deve essere completato manualmente per assegnare e aprire le porte UDP richieste dal plugin Calls. Dalla pagina Software center, assicurarsi che la versione di Mattermost sia la 2.0.0. Clonare quindi l’istanza in esecuzione e, completato il clone, rimuovere la vecchia istanza.

Principali cambiamenti del 2023-09-13#

Beta 2

  • Immagine pre-built – Le immagini si basano su Rocky Linux. I formati disponibili sono .qcow2 per QEMU/Proxmox e .vmdk per VMware. Fare riferimento a Pre-built image per i link di download dell e immagini.

  • Requisiti FQDN – La procedura di creazione del cluster richiede ora di rivedere e impostare il nome host del sistema. Il nome host deve essere fornito in forma breve (una sola parola, senza suffisso di dominio). La procedura richiede anche il suffisso di dominio e manipola il file /etc/hosts aggiungendo un record per risolvere correttamente il fully qualified domain name (FQDN). Per esempio:

    127.0.1.1 node1.example.org node1
    

    Vedi anche DNS configuration.

  • Porta WireGuard 55820 – La porta UDP utilizzata da WireGuard nella creazione del cluster VPN è ora fissata a 55820. La configurazione dei cluster già creati con un numero di porta personalizzato dovrà essere corretta manualmente prima di aggiornare il core a Beta 2. Ad esempio, se la porta personalizzata è 55821 eseguire sul nodo leader i seguenti passaggi per risolvere il problema.

    1. Correggere l’indirizzo di endpoint pubblico VPN in Redis. Ad esempio, se il nodo leader è 1 e il suo FQDN è node1.example.org:

      redis-cli hset node/1/vpn endpoint node1.example.org:55820
      
    2. Correggere la configurazione del firewall

      firewall-cmd --permanent --service=ns-wireguard --remove-port=55821/udp
      firewall-cmd --permanent --service=ns-wireguard --add-port=55820/udp
      firewall-cmd --reload
      
    3. Modificare la porta di ascolto dell’istanza WireGuard in esecuzione

      wg set wg0 listen-port 55820
      
    4. Rendere le modifiche permanenti, impostando ListenPort = 55820 nel file /etc/wireguard/wg0.conf

      sed -ir 's/ListenPort.*/ListenPort = 55820/' /etc/wireguard/wg0.conf
      

    Ripetere i passi da 2 a 4 anche su ogni nodo worker.

  • Aggiornamento Debian – Dopo aver eseguito l’aggiornamento del core, le installazioni basate su Debian 11 (Bullseye) devono essere aggiornate manualmente alla versione di distribuzione 12 (Bookworm)

    rm -f '/etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list'
    sed -i 's/bullseye/bookworm/' /etc/apt/sources.list
    apt update && apt full-upgrade -y
    

    Seguire le istruzioni per aggiornare Python alla versione 3.11, poi riavviare il sistema. Applicare la stessa procedura per ogni nodo del cluster.

  • Python 3.11 – Dopo aver eseguito l’aggiornamento del core, le installazioni basate su Rocky Linux (e altre distribuzioni EL-like) devono installare manualmente Python 3.11:

    dnf install python3.11
    

    Debian necessita anche l’esecuzione del seguente script Bash. Non tralasciare le parentesi tonde!

    (
        set -e -x
        core_dir=/usr/local/agent/pyenv
        mv -v ${core_dir} ${core_dir}.bak
        python3.11 -mvenv ${core_dir} --upgrade-deps --system-site-packages
        ${core_dir}/bin/pip3 install -r /etc/nethserver/pyreq3_11.txt
        echo "/usr/local/agent/pypkg" >$(${core_dir}/bin/python3 -c "import sys; print(sys.path[-1] + '/pypkg.pth')")
        rm -rf ${core_dir}.bak
    )
    

    Controllare se l’aggiornamento Python ha avuto successo:

    runagent python3 --version # output should be 3.11
    

    Applicare la stessa procedura per ogni nodo del cluster.

  • Miglioramenti di sicurezza UI – Con la versione Beta 1 è stato rilasciato un importante aggiornamento di sicurezza, e altri miglioramenti di sicurezza sono ora disponibili. Dopo aver eseguito l’aggiornamento del core, ricaricare la pagina del browser con CTRL + Shift + R o altro metodo equivalente.

  • Backend log migliorato – Il backend della pagina Log di sistema è stato migliorato per essere più veloce e accurato nella cattura dei log di ogni componente cluster. Il modulo core ora gestisce Promtail come servizio di sistema. Dopo aver eseguito l’aggiornamento del core, è possibile disinstallare i moduli di base di Promtail eseguendo questo comando sul nodo leader:

    api-cli run list-installed-modules | jq -r '.["ghcr.io/nethserver/promtail"] | .[].id' | xargs -l remove-module --no-preserve
    

    Attenzione: la nuova pagina dei log non può accedere alle vecchie voci di registro. Per visualizzare le voci di registro precedenti all’aggiornamento Beta 2, utilizzare il comando logcli.

  • Caricamento certificato TLS – Il menu Certificati TLS nella pagina Impostazioni è stato esteso per consentire il caricamento di un certificato e della chiave privata ad esso associata. Si veda la sezione Certificati TLS.

  • Repositori di backup aggiuntivi – I repository di backup possono essere creati anche su cloud storage provider compatibili con Microsoft Azure e S3.

  • Nuova configurazione backend Traefik – Il cluster Redis DB non viene più utilizzato come backend di configurazione dinamica dalle istanze dei moduli Traefik. La configurazione Traefik è ora interamente memorizzata nella home directory del modulo. Per migliorare le prestazioni Redis è possibile disabilitare una funzione specifica per Traefik con i seguenti comandi:

    podman exec redis sed -i.beta1 '/^notify-keyspace-events / d' /data/etc/redis.conf
    systemctl restart redis
    

    Applicare la stessa procedura per ogni nodo del cluster.

  • Miglioramenti modulo mail

    1. Le nuove installazioni del modulo Mail hanno l’opzione Shared visto abilitata per impostazione predefinita. Gli impianti esistenti troveranno l’interruttore disabilitato. Vedi anche la sezione relativa a impostazioni caselle e-mail.

    2. Aggiunto a Dovecot il plugin open source Flatcurve per abilitare la ricerca full-text (FTS) nei messaggi e-mail. Per ricostruire massicciamente gli indici di ricerca eseguire il seguente comando durante il tempo di inattività del sistema:

      podman exec dovecot sh -c "doveadm index -A -q '*' ; pgrep indexer-worker | xargs -- renice"
      

      Solo gli allegati PDF e l’e-mail stessa vengono aggiunti all’indice. In futuro saranno supportati più formati di allegati.

Principali cambiamenti del 2023-05-10#

Beta 1

Le caratteristiche principali del core includono:

  • Gestione dei nodi: aggiunta e rimozione di nodi dal sistema

  • Centralizzazione log: raccolta di tutti i log in un unico posto per un monitoraggio semplificato

  • Backup configurazione e dati: salva regolarmente le impostazioni del cluster e i dati delle applicazioni in provider remoti come Amazon S3 e Backblaze B2

  • Autenticazione: supporto per le directory utente Active Directory e LDAP (RFC2307)

  • File server: implementazione di un file server SMB (Server Message Block) che consente l’integrazione senza soluzione di continuità con le reti basate su Windows

  • Auditing: tracciatura delle modifiche apportate all’interno del sistema per garantire sicurezza e responsabilità

  • Relay e-mail: utilizzo di uno smart host per l’invio delle e-mail in uscita tramite un server affidabile

  • Custom web routing: define custom URLs to handle specific requests

  • Multi-factor authentication: enable two-step verification for administrator accounts

  • Built-in firewall: protect against unauthorized access at the network level by implementing a local firewall

  • Migration: Cockpit module to import NethServer 7 applications

Additional modules:

  • Collaborative tools: includes Dovecot/Postfix/Rspamd mail server, WebTop, Roundcubemail, Nextcloud, Collabora Online, Dokuwiki, ejabberd, Mattermost

  • Development utilities: features MariaDB and NGINX web server for creating dynamic applications and services

  • Monitoring and analysis: offers Grafana, Prometheus, and node_exporter for tracking performance metrics and identifying potential issues

  • Data storage: offers MinIO for managing large amounts of structured and unstructured data

  • Network defense: implements CrowdSec for protecting local applications against remote attacks

The following known limitations will be resolved in future updates:

  • currently, the system only uses TLS certificates issued by Let’s Encrypt or self-signed certificates generated locally

  • user login is not supported on worker nodes

  • the mail module does not offer sender-based or destination-based message relay options

  • only a limited number of cloud storage providers are available for backing up data

Releases glossary#

The software release cycle includes four stages: Alpha, Beta, Release Candidate (RC), and Stable.

During the Alpha stage, the software is not thoroughly tested and may not include all planned features. This release is not suitable for production environments. However, it can be used to preview what’s coming in the upcoming version. Please note that updates from an Alpha release to other releases are not supported.

The Beta stage indicates that the software is mostly feature complete, but it may still contain many known and unknown bugs. This release should not be used on production environments. However, it can be used to test the software before deploying it to production. Updates from a Beta release to an RC or Stable release are supported but may require a manual procedure.

During the Release Candidate (RC) stage, the software is feature complete, and it contains no known bugs. If no major issues arise, it can be promoted to Stable. Updates from an RC release to a Stable release are supported and should be almost automatic. However, if you’re new to the software, it’s best to use it in production only if you already have some experience with it.

The Stable release is the most reliable and safe to use in production environments. It has been thoroughly tested and is considered to be free of major bugs.