Uncategorized

política de protecció de dades Tornar al repte 2.3 1. JUSTIFICACIÓ — Per què necessitem una Política de Protecció de Dades? Marc legal aplicable Com qualsevol empresa que opera a la Unió Europea, estem obligats a complir el Reglament General de Protecció de Dades (RGPD) — Reglament (UE) 2016/679, en vigor des del 25 de maig de 2018. A nivell estatal, també s’aplica la LOPDGDD (Llei Orgànica 3/2018, de 5 de desembre). Per què és important? L’empresa gestiona dades de clients (projectes creatius, correus, facturació) i de treballadors (credencials LDAP, directoris NFS, logs del sistema). Si no protegeix aquestes dades: Pot rebre multes de fins a 20 milions d’euros o el 4% de la facturació anual. Perd la confiança dels clients, que li confien arxius creatius i dades personals. Incompleix les seves obligacions com a responsable del tractament de dades. Quins drets dels usuaris esteu protegint? (a la següent taula) 2. IMPLEMENTACIÓ — Com ho apliquem tècnicament A) Clàusula informativa (per a formularis / accés al sistema) “En compliment del RGPD (UE) 2016/679, les dades personals facilitades seran tractades per LadyUp amb la finalitat de gestionar la relació professional i prestar els serveis contractats. Les dades no seran cedides a tercers sense consentiment exprés. Podeu exercir els vostres drets d’accés, rectificació, supressió i portabilitat enviant un correu a: correu@prova.cat   POSSAR FOTOS (1. 🖥️ Pantalla de login del sistema (LDAP) 2. 📁 Accés FTP )(servidor FTP) B) Registre d’activitats de tractament Aquesta és la llista de dades que el nostre sistema recull, guarda i tracta:  

Compartició de claus SSH amb els companys Tornar al repte 2.3 Objectiu Que tothom de l’equip actual pugui fer ssh usuari@ip_usuari sense posar contrasenya entre tots. Que ningú de fora de l’equip actual (ni equips anteriors) hi tingui accés. Copia la teva clau pública (la que donaràs als altres) Executa aquest comandament per veure-la i copiar-la fàcilment. Un cop la tens  copia tot el text que surt.  Copia tot el text que surt i envia la teva clau pública a tots els companys i al professor. Tothom hauria de fer el mateix. cat ~/.ssh/id_ed25519.pub Afegeix les claus públiques dels companys al teu portàtil ssh-copy-id usuari@192.168.1.55 Copiar al portàtil del Cristian: Copiar al portàtil de l’Andres: Copiar al portàtil de l’Hector: Ara podem fer ssh amb els nostres companys d’equip.  Ells fan el mateix desde la seva màquina i podem connectarnos a la màquina de cada un de l’equip.

Mitjans de suport Tornar al repte 2.2 SAI (Sistema d’Alimentació Ininterrumpida, o UPS en anglès), és com una bateria de reserva que manté tot encès uns minuts (o més) perquè puguis apagar-ho amb seguretat o esperar que torni la llum. És essencial en entorns com torres de telecomunicacions, on un tall pot significar pèrdua de connexió, dades o fins i tot seguretat.   Objectiu Calcular tota la potència consumida per la torre completa (pasarel·la + switch + el que sigui essencial) i triar un SAI que aguanti com a mínim 15–20 minuts en cas de tall de llum (temps més que suficient perquè algú arribi o per engegar un generador/portàtil). Mètode (sense hardware extra) Fem una estimació molt precisa combinant: Consum de la CPU/RAM/disks del servidor → ho mesurem amb comandes. Consum del switch → el sabem pels logs o pel model (t’ho miro amb la IP). Petits consums fixos (fonts d’alimentació, cables, etc.). 1. Entra a la pasarel·la  ssh teu_usuari@172.25.203.12 3. Mira quanta càrrega té ara mateix la CPU top -bn1 | grep "Cpu(s)” %Cpu(s):  0.0 us, 33.3 sy,  0.0 ni, 66.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st 2. Mira quin processador té cat /proc/cpuinfo | grep "model name" | head -1 model name    : Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz Càlcul del rendiment necessari del SAI per a la torre/passarel·la (IP 172.25.203.12) Escenari real en cas d’apagada a l’aula La pasarel·la (172.25.203.12) i el switch D-Link cauen → tota la classe perd internet i xarxa interna immediatament. Els 3 portàtils Linux tenen bateria pròpia → poden seguir funcionant 1–4 hores segons el model, però sense xarxa no serveixen de res per a la classe. Per tant, l’únic objectiu útil del SAI és mantenir viva la pasarel·la + switch el temps suficient per: Acabar la classe amb normalitat (encara que siguin només 15–30 minuts). O donar temps als alumnes a desar el treball i apagar ordenadament NO cal connectar els portàtils al SAI.   Els portàtils ja tenen bateria pròpia (normalment 2–4 hores reals en ús de classe). El SAI de 800–1000 VA que hem calculat no té endolls suficients ni potència per alimentar 3 portàtils més sense reduir l’autonomia a menys de 10 minuts (cada portàtil pot arribar a 30–60 W quan carrega a tope). Connectar-los faria que el SAI saltés per sobrecàrrega en menys de 5 minuts → pitjor que no tenir SAI. En un centre educatiu el protocol habitual és: «si hi ha apagada, els alumnes guarden el treball amb la bateria del portàtil i la classe acaba o es trasllada». Consum real mesurat i contrastat Pasarel·la i5-6400 (33 % ús fent DHCP/routing/VLANs): 65 W en ús normal → 75 W valor màxim amb pics Switch D-Link DGS-1100-05V2 (3 ports actius): 6 W màxim  Pèrdues de fonts i accessoris: 9 W Consum total màxim de la torre: 75 + 6 + 9 = 90 W Aleshores:  Requisits del SAI Tipus: line-interactive amb ona senoidal pura i AVR Capacitat mínima: 1000 VA / 600 W Autonomia mínima exigida: 30 minuts a 90 W Només s’alimentaran la pasarel·la i el switch (els portàtils tenen bateria pròpia i no es connectaran) Model seleccionat i justificat Salicru SPS 1000 SOHO+ Preu orientatiu: 165-185 €. 1000 VA / 600 W Autonomia real amb 90 W: 42–48 minuts (segons taules oficials del fabricant) Onda senoidal pura + regulació automàtica de tensió 6 endolls Schuko + port USB per apagat controlat Preu orientatiu: 165–185 € (desembre 2025) Ona senoidal pura + regulació automàtica de tensió (AVR): vol dir que el SAI entrega una electricitat idèntica a la de la paret (forma i tensió estable) tant en mode normal com amb bateria, cosa que garanteix màxima compatibilitat i protecció per a la pasarel·la i el switch sense desgastar innecessàriament les bateries. Per què NO connectem els portàtils al SAI Cada portàtil pot consumir 30–60 W quan carrega → 3 portàtils = +90–180 W L’autonomia cauria a menys de 10 minuts i hi ha risc de sobrecàrrega Els portàtils ja tenen 2–4 hores de bateria → la prioritat és mantenir la xarxa viva, no carregar bateries enllaç 1- https://www.salicru.com/files/documentacion/ek97601%281%29.pdf enllaç 2-  https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://www.salicru.com/files/documentacion/ficha-castellano(1).pdf&ved=2ahUKEwjk18y0456RAxUkT6QEHSw-LR0QFnoECBgQAQ&usg=AOvVaw2ONTsJkUbKZvyW8vZUPtOF

CONFIGURACIÓ DOVECOT – SERVIDOR DE CORREU ENTRANT Tornar al repte 2.2 PART 1: CREACIÓ D’USUARIS DEL SISTEMA 1.1 – CREAR ELS USUARIS useradd [opcions] nom_usuari Verifica que els directoris home s’han creat: ls -la /home/ 1.2 – ASSIGNAR CONTRASENYES ALS USUARIS SEGUINT LA NOSTRA POLÍTICA DE CONTRASENYAS passwd nom_usuari PART 2: INSTAL·LACIÓ DE DOVECOT 2.1 – REPOSITORIS I FONTS DEL PAQUET Concepte: Què és un repositori? Un repositori és un servidor que conté paquets de programari compilats i preparats per instal·lar.  A Rocky Linux, els repositoris oficials són: BaseOS: Paquets base del sistema operatiu AppStream: Aplicacions i eines addicionals Extras: Paquets complementaris Comprovem quins repositoris tenim actius i busquem Dovecot als repositoris:: dnf repolist dnf search dovecot Què són aquests paquets? dovecot: Paquet principal (IMAP/POP3) dovecot-pigeonhole: Plugin per filtres de correu (Sieve) dovecot-mysql/pgsql: Per usuaris virtuals en base de dades. 2.2 – INSTAL·LACIÓ DE DOVECOT dnf install dovecot -y Verifica que s’ha instal·lat correctament: # Versió de Dovecot dovecot –version # Estat del servei (encara no està iniciat) systemctl status dovecot # Fitxers instal·lats rpm -ql dovecot | head -20 PART 3: CONFIGURACIÓ DE DOVECOT 3.1 – CÒPIA DE SEGURETAT (MOLT IMPORTANT!)   Concepte: Per què fer còpies de seguretat? Abans de modificar QUALSEVOL fitxer de configuració, SEMPRE has de fer una còpia de seguretat. Per què? Si fas un error, pots recuperar la configuració original Pots comparar els canvis que has fet És una pràctica professional obligatòria. Fem la còpia de seguretat: # Copiar tot el directori de configuració cp -r /etc/dovecot /etc/dovecot.backup # Verificar que s'ha copiat ls -la /etc/ | grep dovecot Ara ja pots modificar fitxers amb tranquil·litat! Si fas malbé alguna cosa, pots restaurar amb:   rm -rf /etc/dovecot cp -r /etc/dovecot.backup /etc/dovecot Editem el fitxer de configuració: vim /etc/dovecot/conf.d/10-mail.conf Busca la línia mail_location.  Aquesta línia està comentada (té # al davant), per tant no està activa. Modifica-la així: # ABANS #mail_location = mbox:~/mail:INBOX=/var/mail/%u # DESPRÉS # Ubicació dels correus: format Maildir al directori home de cada usuari # maildir: indica el format Maildir (un fitxer per correu) # ~/Maildir: cada usuari tindrà una carpeta Maildir al seu home (/home/usuari/Maildir) # Aquest format és més segur, ràpid i fiable que mbox mail_location = maildir:~/Maildir Explicació línia per línia: maildir: → Especifica que usem format Maildir ~/Maildir → ~ significa el home de l’usuari (/home/aborrego/Maildir) Cada usuari tindrà la seva pròpia carpeta Maildir 3.3 – CREAR LES CARPETES MAILDIR PER ALS USUARIS   Cada usuari necessita tenir aquesta estructura creada:    /home/usuari/Maildir/├── new/ ← Aquí arriben els correus nous├── cur/ ← Correus llegits o marcats└── tmp/ ← Zona temporal durant la recepció   Per què 3 carpetes? tmp/: Quan arriba un correu, primer es guarda aquí (per evitar corrupció) new/: Quan el correu està complet, es mou aquí (correu nou, no llegit) cur/: Quan l’usuari llegeix el correu, es mou aquí Creem les carpetes per cada usuari: # Usuari: aborrego mkdir -p /home/aborrego/Maildir/{new,cur,tmp} chown -R aborrego:aborrego /home/aborrego/Maildir chmod -R 700 /home/aborrego/Maildir # Usuari: alozano mkdir -p /home/alozano/Maildir/{new,cur,tmp} chown -R alozano:alozano /home/alozano/Maildir chmod -R 700 /home/alozano/Maildir # Usuari: hbravo mkdir -p /home/hbravo/Maildir/{new,cur,tmp} chown -R hbravo:hbravo /home/hbravo/Maildir chmod -R 700 /home/hbravo/Maildir 3.4 – CONFIGURACIÓ DE PROTOCOLS (IMAP, POP3, LMTP) Concepte: Protocols de correu   IMAP (Internet Message Access Protocol) – Port 143/993 Client ←──→ Servidor  Com funciona: Els correus es queden al servidor Avantatge: Sincronització entre múltiples dispositius (mòbil, PC, web) Ideal per: Usuaris que accedeixen des de múltiples llocs Port 143**: IMAP sense xifrar – NO recomanat Port 993**: IMAPS (IMAP amb SSL/TLS) – RECOMANAT POP3 (Post Office Protocol) – Port 110/995** Client ←── Servidor Com funciona: Descarrega els correus al client i els esborra del servidor. Desavantatge: Els correus només estan en 1 dispositiu Ideal per: Usuaris amb 1 sol dispositiu i espai limitat al servidor – Port 110**: POP3 sense xifrar (NO recomanat) – Port 995**: POP3S (POP3 amb SSL/TLS) – RECOMANAT   LMTP (Local Mail Transfer Protocol) Postfix ──→ Dovecot (SMTP) (LMTP) Editem el fitxer principal de Dovecot: Busca la línia protocols. Modifica-la així: # ABANS: #protocols = imap pop3 lmtp submission # DESPRÉS: protocols = imap pop3 lmtp Què són aquests paquets? dovecot: Paquet principal (IMAP/POP3) dovecot-pigeonhole: Plugin per filtres de correu (Sieve) dovecot-mysql/pgsql: Per usuaris virtuals en base de dades. 3.5 – CONFIGURACIÓ D’AUTENTICACIÓ Concepte: Com s’autentiquen els usuaris?   Quan un usuari intenta accedir al seu correu, Dovecot ha de verificar la seva identitat:    Client: “Soc aborrego, la meva contrasenya és XYZ” Dovecot: “Deixa’m comprovar…” Dovecot comprova → /etc/shadow Dovecot: “Correcte! Aquí tens els teus correus”   Mecanismes d’autenticació: Nosaltres usarem PLAIN i LOGIN sobre SSL/TLS (segur i compatible).   Editem el fitxer d’autenticació: vi /etc/dovecot/conf.d/10-auth.conf Busca i modifica aquestes línies: 1. Desactivar autenticació en text pla sense SSL: # BUSCA: disable_plaintext_auth = yes # MODIFICA A: disable_plaintext_auth = yes # Desactivar autenticació en text pla sense SSL/TLS # Això força que els usuaris SEMPRE usin connexions xifrades (IMAPS/POP3S) # Si intenten connectar sense SSL amb usuari/contrasenya, es rebutjarà 2. Mecanismes d’autenticació: # BUSCA: auth_mechanisms = plain # MODIFICA A: auth_mechanisms = plain login # Mecanismes d'autenticació permesos: # – plain: usuari i contrasenya (sobre SSL és segur) # – login: compatible amb més clients de correu (Outlook, etc.) 3. Habilitar autenticació amb usuaris del sistema: # BUSCA: #!include auth-system.conf.ext # MODIFICA A: !include auth-system.conf.ext # Incloure configuració per autenticar amb usuaris del sistema Linux # Això permet que aborrego, alozano i hbravo s'autentiquin amb les seves contrasenyes 4. Desactivar altres mètodes d’autenticació (per ara): ASSEGURA’T que aquestes línies ESTAN comentades (amb #): # No utilitzem autenticació SQL per ara (ho farem després per usuaris virtuals) #!include auth-sql.conf.ext # No utilitzem LDAP #!include auth-ldap.conf.ext # No utilitzem base de dades estàtica #!include auth-static.conf.ext PART 4: CONFIGURACIÓ SSL/TLS 4.1 – CONCEPTE: Què és SSL/TLS i per què és important?   SSL/TLS (Secure Sockets Layer / Transport Layer Security) Quan un client de correu (Outlook, Thunderbird, mòbil) es connecta al servidor: Sense SSL/TLS: Client ─────→ [usuari: aborrego] [password: 1234] ─────→ Servidor … Read more

Connexió client linux Tornar al repte 2.2 Què és Active Directory (AD)? És un servei de Windows Server que funciona com una “base de dades centralitzada” d’usuaris, ordinadors i permisos. Quan connectem el Debian a l’AD, podrem iniciar sessió amb usuaris que estan al servidor de Windows.   Què necessitem? realmd: Eina que descobreix i connecta automàticament al domini sssd: Servei que gestiona l’autenticació amb l’AD adcli: Eina per administrar la connexió al domini samba-common-bin: Eines per treballar amb protocols de Windows El meu entorn: DNS Master (Debian): illa4.local Windows Server (AD): smx.illa4 – IP: 10.4.0.70 Client Debian: El que connectarem ara. Configurar el DNS Master PAS 1: Afegir la zona del domini AD Al teu DNS Master, edita la configuració: sudo nano /etc/bind/named.conf.local PAS 2: Crear el fitxer de zona per a l’AD Crea el fitxer de zona: sudo nano /etc/bind/db.smx.illa4 PAS 3: Verificar la configuració i reiniciar BIND9 Comprova que no hi ha errors de sintaxi i si tot està bé, reinicia BIND9: sudo named-checkconf sudo named-checkzone smx.illa4 /etc/bind/db.smx.illa4 sudo systemctl restart bind9 sudo systemctl status bind9 Pas 4: Provar el DNS Master Des del mateix DNS Master, prova: ping smx.illa4 ping ad.smx.illa4 nslookup smx.illa4 Configurar el DNS al Windows Server Opció A – Des de l’interfície gràfica: Accedir a les Propietats de Xarxa: Obriu el “Panel de control” i aneu a “Xarxes i Internet” > “Centre de xarxes i recursos compartits”. Feu clic a “Canvia la configuració de l’adaptador”. Feu clic dret a l’adaptador de xarxa (Ethernet o Wi-Fi) i seleccioneu Propietats. Configurar IPv4: Selecciona Protocol d’Internet versió 4 (TCP/IPv4) Fes clic a Propietats Marca l’opció “Utilitza les adreces de servidor DNS Posa l’IP del teu servidor Debian (el DNS Master/Controlador de Domini). Com que només tenim el DNS Master, hi han dues opcions: Deixar-lo buit, posar 127.0.0.1 (loopback) o 8.8.8.8 com a fallback (però no és l’ideal per a un entorn AD) Servidor DNS preferido: 10.4.0.10 (el teu DNS Master) Servidor DNS alternativo: 127.0.0.1 (el propi Windows Server, com a backup) Clica Aceptar i tanca les finestres. Verificar la configuració i provar que funciona # Veure la configuració DNS Get-DnsClientServerAddress # O amb ipconfig ipconfig /all # Fer ping ping smx.illa4 ping 10.4.0.10 “` Configurar el DNS Master PAS 1: Afegir la zona del domini AD Al teu DNS Master, edita la configuració: sudo nano /etc/bind/named.conf.local PAS 2: Crear el fitxer de zona per a l’AD Crea el fitxer de zona: sudo nano /etc/bind/db.smx.illa4 PAS 3: Verificar la configuració i reiniciar BIND9 Comprova que no hi ha errors de sintaxi i si tot està bé, reinicia BIND9: sudo named-checkconf sudo named-checkzone smx.illa4 /etc/bind/db.smx.illa4 sudo systemctl restart bind9 sudo systemctl status bind9 Pas 4: Provar el DNS Master Des del mateix DNS Master, prova: ping smx.illa4 ping ad.smx.illa4 nslookup smx.illa4 Configurar el DNS al Windows Server Opció A – Des de l’interfície gràfica: Accedir a les Propietats de Xarxa: Obriu el “Panel de control” i aneu a “Xarxes i Internet” > “Centre de xarxes i recursos compartits”. Feu clic a “Canvia la configuració de l’adaptador”. Feu clic dret a l’adaptador de xarxa (Ethernet o Wi-Fi) i seleccioneu Propietats. Configurar IPv4: Selecciona Protocol d’Internet versió 4 (TCP/IPv4) Fes clic a Propietats Marca l’opció “Utilitza les adreces de servidor DNS Posa l’IP del teu servidor Debian (el DNS Master/Controlador de Domini). Com que només tenim el DNS Master, hi han dues opcions: Deixar-lo buit, posar 127.0.0.1 (loopback) o 8.8.8.8 com a fallback (però no és l’ideal per a un entorn AD) CONNEXIÓ DEL CLIENT DEBIAN AL DOMINI Configurar el DNS del client Ho configurem amb la primera línea de comandes i ho fem immutable amb la segona. sudo nano /etc/resolv.conf sudo chattr +i /etc/resolv.conf Verificar connectivitat Al client Debian, vaig comprovar la connectivitat: ping 10.4.0.20 # Windows Server → ✅ Funciona ping 10.4.0.10 # DNS Master → ❌ No funciona ping smx.illa4 # Nom del domini → ❌ No resol nslookup smx.illa4 # → ❌ No resol Vaig comprovar la configuració de xarxa del client: ip addr show ip route show Problema detectat: Client Debian: 10.4.0.220/27 (xarxa 10.4.0.192 – 10.4.0.223) DNS Master: 10.4.0.10/25 (xarxa 10.4.0.0 – 10.4.0.127) Windows Server: 10.4.0.20/25 (xarxa 10.4.0.0 – 10.4.0.127) Conclusió: El client està en una VLAN diferent (10.4.0.192/27) respecte al DNS Master i Windows Server (10.4.0.0/25).   Context: DNS Master i Windows Server: Estan al meu ordinador, connectats a la VLAN 10.4.0.0/25 Client Debian: Està a l’ordinador del meu company, connectat a la VLAN 10.4.0.192/27 Connexió: Tots dos ordinadors estan connectats al mateix switch, però en VLANs diferents Proves de connectivitat entre VLANs Des del client, vaig provar la connectivitat amb cada servidor: ping 10.4.0.10 # DNS Master → ❌ 100% packet loss ping 10.4.0.20 # Windows Server → ✅ Funciona! Descobriment important: Hi ha routing parcial entre VLANs: ✅ El client SÍ pot arribar al Windows Server ❌ El client NO pot arribar al DNS Master Solució implementada: Usar el Windows Server com a DNS Com que el client té connectivitat amb el Windows Server però no amb el DNS Master, vaig decidir configurar el Windows Server com a servidor DNS per al client. Configuració al Windows Server 1. Verificar i engegar el servei DNS Get-Service DNS Start-Service DNS Set-Service DNS -StartupType Automatic 3. Verificar la resolució DNS Resultat: Resol correctament a 10.4.0.20 ✅ nslookup smx.illa4 127.0.0.1 2. Comprovar que escolta a totes les interfícies Resultat: ListenAddresses buit → Escolta a totes les interfícies ✅ Get-DnsServerSetting -All | Select-Object ListenAddresses Modificar el servidor DNS Vaig canviar la configuració del client per usar el Windows Server com a DNS: # Treure l'atribut immutable sudo chattr -i /etc/resolv.conf # Editar el fitxer sudo nano /etc/resolv.conf Proves finals de connectivitat nslookup smx.illa4 ping smx.illa4 Instal·lació de paquets per a la integració amb Active Directory sudo apt update sudo apt install -y realmd sssd sssd-tools libnss-sss libpam-sss adcli samba-common-bin packagekit realmd: Eina que descobreix i connecta automàticament al domini sssd: Servei que gestiona l’autenticació amb usuaris d’Active Directory adcli: Eines per administrar la connexió al domini libnss-sss i … Read more

Control de versions de codi Tornar al repte 2.2 1.1 Què és el Control de Versions? Treballar en equip sense conflictes Mantenir un historial complet de canvis Recuperar versions anteriors del codi Identificar qui va fer cada canvi i quan Experimentar amb noves funcionalitats sense por de perdre el treball anterior 2.1 Avantatges Principals de Git Desenvolupar noves funcionalitats de forma aïllada Experimentar sense afectar el codi principal Treballar en múltiples tasques simultàniament Mantenir el codi de producció sempre estable   Fonts d’Informació Oficials Pàgina oficial de Git: https://git-scm.com/about Documentació oficial: https://git-scm.com/doc Llibre Pro Git (gratuït): https://git-scm.com/book Atlassian Git Tutorial: https://www.atlassian.com/git/tutorials/why-git Stack Overflow Developer Survey 2022: Estadístiques d’adopció sudo systemctl status postfix sudo systemctl enable postfix.

Configuració del servidor de correu sortint corporatiu (postfix) Tornar al repte 2.2 Pas 1: Instal·lació 1 Preparació de l’Entorn: Assegura’t que estàs connectat al teu servidor dedicat per correu. El servidor ha de tenir un nom de domini FQDN (Fully Qualified Domain Name) correcte, com “correu.makrosoft.cat”. Per comprovar-ho, executa hostname -f a la terminal. Si no és correcte, edita el fitxer /etc/hostname amb sudo nano /etc/hostname, afegeix el nom (p. ex., “correu”), desa i reinicia amb sudo reboot. 2 Instal·lació Postfix: Utilitzo dnf perquè Rocky Linux és basada en Red Hat, i dnf és l’eina de gestió de paquets estàndard. Instal·lo Postfix des dels repositoris oficials per garantir seguretat i compatibilitat. Executa la següent linea de comandes. L’opció -y confirma automàticament per accelerar el procés en un entorn de prova. sudo dnf install postfix -y 3 Verificació: Comprovo l’estat del servei per confirmar que s’ha instal·lat correctament i està actiu. Això verifica que no hi hagi errors d’instal·lació i que el servei estigui llest per a la configuració. Executa la següent linea de comandes.  sudo systemctl status postfix Si no està actiu, inicia’l Executa la següent linea de comandes i habilita’l per arrencar automàticament. sudo systemctl status postfix sudo systemctl enable postfix. Pas 2: Implementació Aquest pas configura Postfix per permetre l’enviament de correus sortints 1 Edició de la Configuració Edito el fitxer principal /etc/postfix/main.cf perquè és on es defineixen les opcions bàsiques de Postfix. Executa la següent línea de comandes. vim /etc/postfix/main.cf Aquest fitxer controla el comportament global de Postfix. Canviem només el necessari per mantenir la configuració neta i evitant errors. 2 Paràmetres Mínims: Configuro els paràmetres essencials segons la rúbrica. Per ✅ PRO+, afegeixo un comentari (#) abans de cada un per demostrar comprensió. Afegeix o modifica aquestes línies al fitxer (amb comentaris): # Aquesta línia configura el nom complet del servidor, necessari per a la identificació en xarxes. myhostname = correu.makrosoft.cat # Aquesta línia defineix el domini principal de l'empresa, utilitzat per a adrecis de correu. mydomain = makrosoft.cat # Aquesta línia indica el domini que apareixerà com a origen en els correus enviats. myorigin = $mydomain # Aquesta línia especifica les xarxes locals permeses per enviar correus (evita spam extern). Inclou localhost i la xarxa interna (substitueix 192.168.1.0/24 pel teu rang real). mynetworks = 127.0.0.0/8 192.168.1.0/24 3 Reinici del Servei: Reinicio Postfix per aplicar els canvis, sense reinici, els canvis no s’apliquen. Això assegura que la configuració nova estigui activa. I verifico que no hi hagi errors. Executa la següent linea de comandes.  sudo systemctl restart postfix sudo systemctl status postfix Si vols veure només els paràmetres actius (sense duplicats ni comentaris): postconf -n Prova de Servei: Instal·la una eina per enviar correus des de la línia de comandaments A Rocky Linux (versió 8 o 9), el paquet clàssic mailx ha estat substituït per s-nail (és el mateix funcionalment, només canvia el nom del comandament: mail segueix funcionant). sudo dnf install s-nail   2. Envia un correu de prova a una adreça externa Executa aquesta comanda (substitueix teuemail@gmail.com per la teva adreça real):