aborrego

Configuració del DNS Master a debian Tornar al repte 2.2 Pas 1: Instal·lació de BIND9 i les utilitats Actualitza la llista de paquets i instal·la BIND9 # Actualitza la llista de paquets sudo apt update # Instal·la el paquet BIND9 i les utilitats sudo apt install bind9 bind9utils -y El servei BIND9 s’iniciarà automàticament després de la instal·lació, però encara no farà res útil amb el teu domini. Pas 2: Configuració de la Zona al Fitxer Local Has d’indicar a BIND9 que és el Master (Mestre) per al teu domini. Això es fa al fitxer de configuració local. Edita el fitxer /etc/bind/named.conf.local: sudo nano /etc/bind/named.conf.local Afegim el següent al final del fitxer: // Zona directa per illa4.local zone "illa4.local" { type master; file "/etc/bind/db.illa4.local"; }; // Zona inversa per la xarxa 10.4.0.0/25 (reverse lookup per 10.4.0.x) zone "0.4.10.in-addr.arpa" { type master; file "/etc/bind/db.10.4.0"; }; La zona directa gestiona noms a IPs (A records). La zona inversa gestiona IPs a noms (PTR records). Per la xarxa 10.4.0.0/25, utilitzem “0.4.10.in-addr.arpa” (que cobreix el /24 sencer, però només afegirem entrades per la teva subxarxa). Si només vols /25, això funciona igualment. 1.4 Creació dels Fitxers de Zona Fitxer de zona directa: /etc/bind/db.illa4.local Copia una plantilla: Edita /etc/bind/db.illa4.local: cp /etc/bind/db.local /etc/bind/db.illa4.local nano /etc/bind/db.illa4.local Substituim el contingut amb això (adapta si cal): ; ; BIND data file for illa4.local ; $TTL 604800 @ IN SOA ns1.illa4.local. root.illa4.local. ( 1 ; Serial (incrementa cada canvi) 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS ns1.illa4.local. ns1 IN A 10.4.0.10 1.5 Fitxer de zona inversa: /etc/bind/db.10.4.0 Copia una plantilla: Edita /etc/bind/db.10.4.0: cp /etc/bind/db.127 /etc/bind/db.10.4.0 nano /etc/bind/db.10.4.0 Substituim el contingut amb això (adapta si cal): ; ; BIND reverse data file for 10.4.0.0/25 ; $TTL 604800 @ IN SOA ns1.illa4.local. root.illa4.local. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS ns1.illa4.local. 10 IN PTR ns1.illa4.local. Explicació: PTR: Per l’IP 10.4.0.10, apunta a ns1.illa4.local. El “10” és la part final de l’IP (ja que la zona és 0.4.10.in-addr.arpa). Si afegeixes més IPs, afegeix més PTR, ex: 20 IN PTR www.illa4.local.. 1.6 Verificació i Inici Verifica la sintaxi de les configuracions: named-checkconf /etc/bind/named.conf.local named-checkzone illa4.local /etc/bind/db.illa4.local named-checkzone 0.4.10.in-addr.arpa /etc/bind/db.10.4.0 Reinicia BIND9:   systemctl restart bind9 systemctl status bind9 # Verifica que estigui actiu sense errors Resum final de comprovacions Si totes aquestes comandes mostren el que s’espera (com al meu exemple), el teu DNS Master està 100 % operatiu i correctament configurat. # 1. Comprovar que no hi ha errors de sintaxi named-checkconf && echo "✅ Configuració global OK" named-checkzone illa4.local /etc/bind/db.illa4.local && echo "✅ Zona directa OK" named-checkzone 0.4.10.in-addr.arpa /etc/bind/db.10.4.0 && echo "✅ Zona inversa OK" # 2. Comprovar que BIND està corrent sense errors systemctl status bind9 | grep "Active: active (running)" && echo "✅ Servei BIND actiu" # 3. Consulta directa (forward) → ha de tornar l’IP dig ns1.illa4.local @10.4.0.10 +short # → Ha de mostrar: 10.4.0.10 # 4. Consulta inversa (reverse) → ha de tornar el nom dig -x 10.4.0.10 @10.4.0.10 +short # → Ha de mostrar: ns1.illa4.local. # 5. Comprovar flags correctes (autoritzat i amb resposta) dig ns1.illa4.local @10.4.0.10 | grep -A2 "ANSWER SECTION" # → Ha de mostrar alguna cosa com: # ns1.illa4.local. 604800 IN A 10.4.0.10 # i a dalt: flags: qr aa rd ra # 6. (Opcional però recomanable) Forçar que la màquina es resolgui a si mateixa echo "nameserver 10.4.0.10" > /etc/resolv.conf nslookup ns1.illa4.local # ← ha de resoldre’s correctament

Desplegament amb vagarant Tornar al repte 2.2 Per què triar Vagrant Eina / Mètode Només VirtualBox/VMware manual Què fa Crear i configurar VMs a mà Avantatges Control total Problemes per a aquest repte Molt temps, no reproducible, cada persona ho fa diferent Per què NO l’he triat No és portable ni repetible Eina / Mètode Docker Què fa Contenidors lleugers Avantatges Molt ràpid i lleuger Problemes per a aquest repte No és una màquina completa → no puc provar diferents SO ni instal·lar serveis que necessitin un kernel diferent Per què NO l’he triat No cobreix el 100 % dels casos del repte Eina / Mètode Ansible (només configuració) Què fa Configura màquines ja existents Avantatges Excel·lent per configuració Problemes per a aquest repte No crea ni gestiona les VMs, he de fer-ho a mà abans Per què NO l’he triat Solució a mitges Eina / Mètode Vagrant Què fa Crea i configura VMs automàticament Avantatges → Un sol fitxer (Vagrantfile) → Funciona igual a Windows, Mac i Linux → vagrant up i ja està → Pots usar VirtualBox, VMware, Hyper-V o fins i tot Problemes per a aquest repte Cap desavantatge important per aquest ús Per què NO l’he triat És la millor opció Motius concrets pels quals Vagrant és la millor elecció aquí Portabilitat total – Tothom de l’equip (o el professor) només ha de fer vagrant up i té exactament el mateix entorn, independentment del seu sistema operatiu. Reproduïbilitat 100 % – Tot queda escrit en un sol fitxer Vagrantfile (box, memòria, ports, carpetes compartides, provisioning amb shell/Ansible/Puppet…). Facilitat extrema – En 10-15 línies de codi tinc una VM amb Ubuntu 24.04, 2 GB RAM, port 8080 redirigit, carpeta del projecte sincronitzada i paquets instal·lats automàticament.. Desplegament Vagrant Estructura de carpetes: Dins de la carpeta desplegament_vagrant2 hi ha un Vagrantfile, configurat amb les boxes que necessitem: # -*- mode: ruby -*- # vi: set ft=ruby : Vagrant.configure("2") do |config| # ═══════════════════════════════════════════════════════════ # Windows 10 # ═══════════════════════════════════════════════════════════ config.vm.define "win10" do |win| win.vm.box = "windows10-local" win.vm.hostname = "win10-local" # Bridge: tria tu la interfície de xarxa (Wi-Fi o cable) win.vm.network "public_network", bridge: "enp3s0" # Linux # win.vm.network "public_network", bridge: "Wi-Fi" # Windows (nom exacte de la teva targeta) # win.vm.network "public_network", bridge: "en0: Wi-Fi" # macOS (normalment en0 o en1) win.vm.provider "virtualbox" do |vb| vb.name = "Windows10-Local-Bridge" vb.memory = 8192 # 8 GB RAM (ajusta si cal) vb.cpus = 4 vb.gui = true # posa false si la vols headless vb.customize ["modifyvm", :id, "–vram", "128"] vb.customize ["modifyvm", :id, "–clipboard", "bidirectional"] vb.customize ["modifyvm", :id, "–draganddrop", "bidirectional"] end end # ═══════════════════════════════════════════════════════════ # Ubuntu # ═══════════════════════════════════════════════════════════ config.vm.define "ubuntu", primary: true do |ub| ub.vm.box = "ubuntu-local" ub.vm.hostname = "ubuntu-local" ub.vm.network "public_network", bridge: "enp3s0" # canvia pel teu adaptador ub.vm.provider "virtualbox" do |vb| vb.name = "Ubuntu-Local-Bridge" vb.memory = 4096 vb.cpus = 2 vb.gui = true end end # ═══════════════════════════════════════════════════════════ # Debian # ═══════════════════════════════════════════════════════════ config.vm.define "debian" do |deb| deb.vm.box = "debian-local" deb.vm.hostname = "debian-local" deb.vm.network "public_network", bridge: "enp3s0" # canvia pel teu adaptador deb.vm.provider "virtualbox" do |vb| vb.name = "Debian-Local-Bridge" vb.memory = 2048 vb.cpus = 2 vb.gui = true end end end Si fem vagrant up “nom_box” la màquina es crea.

Eines de seguretat Tornar al repte 2.2 Llista dels cinc tipus de programari maliciós (malware) més comuns i perillosos per a una empresa Els tipus de malware més prevalents i perillosos per a les empreses inclouen variants sofisticades que combinen robatori de dades, control remot i extorsió financera. Aquests tipus no només causen pèrdues econòmiques directes (com pagaments de rescat o downtime operatiu), sinó que també comprometen la confidencialitat de dades sensibles i la reputació corporativa. Ransomware Encripta fitxers i sistemes essencials, exigint un pagament (normalment en criptomonedes) per desbloquejar-los. Sovint es combina amb exfiltració de dades per augmentar la pressió. Troians (incloent RATs – Remote Access Trojans) Es disfressen com a software legítim (ex.: actualitzacions o factures) per obtenir accés remot al sistema, permetent l’execució de comandes malicioses. Spyware/Infostealers Recopila informació confidencial (credencials, sessions de navegació, dades personals) sense consentiment, sovint via keyloggers o capturadors de pantalla. Cryptojackers/Miners Utilitzen la potència de processament de l’ordinador infectat per minar criptomonedes en segon pla, sense que l’usuari ho noti immediatament. Rootkits S’amaguen profundament en el sistema operatiu per ocultar altres malware, evitant detecció i mantenint accés privilegiat. Selecció de l’Eina Hem de triar una que sigui oficial i confiable per evitar riscos. Fonts oficials on siguin descàrregues directes del fabricant, no de llocs sospitosos que podrien tenir malware. Criteris per triar: Cobertura àmplia: Ha de protegir contra molts tipus de malware (virus, troians, ransomware, spyware, rootkits, etc.), no només virus bàsics. Actualitzacions automàtiques: S’ha d’actualitzar sol per detectar amenaces noves (el malware evoluciona ràpidament!). Fàcil d’usar: Per a empreses com Makrosoft, ha de ser integrable en VMs sense complicacions. Gratuïta o baixa cost: Idealment gratuïta per començar. Seguretat a la pasarel·la 1: Antivirus – Recomanació: ClamAV Instal·lació i configuració sudo apt install clamav clamav-daemon -y Actualitza la base de dades de virus (pot trigar una mica la primera vegada). sudo freshclam Escaneja tot el sistema (escaneja tot, pot trigar hores; afegeix -i per només mostrar infectats). sudo clamscan -r / Solucionar els errors típics # Crea el directori que li falta sudo mkdir -p /var/lib/clamav sudo chown clamav:clamav /var/lib/clamav # Arregla permisos dels logs sudo touch /var/log/clamav/freshclam.log sudo chown clamav:clamav /var/log/clamav/*.log sudo chmod 664 /var/log/clamav/*.log # Desactiva el log de freshclam per evitar el famós error de "lock" sudo sed -i 's/^UpdateLogFile.*/#UpdateLogFile/' /etc/clamav/freshclam.conf 2. Escàner de Vulnerabilitats – Recomanació: Lynis Instal·lació i configuració sudo apt install lynis -y. Executa un escaneig sudo lynis audit system El Lynis que tenim instal·lat amb apt install lynis a Ubuntu/Debian és una versió una mica antiga i no té les comandes lynis show … (van aparèixer a partir de la 3.0). Però no cal reinstal·lar res. Amb la versió que tenim (la més normal) els resultats es veuen així de fàcil: # Només les línies amb advertències greus grep -A2 -B2 "warning" /var/log/lynis.log | grep -v "^–" # Només les suggerències grep -A2 -B2 "suggestion" /var/log/lynis.log | grep -v "^–" No tenim cap warning real (l’única cosa que surt és un test de Docker que s’ha saltat perquè no tens Docker instal·lat → és normal i no és cap problema). No tenim cap suggestion tampoc (la segona comanda no ha tret res). Seguretat en un servidor Debian com a DNS Master Actualització i Eliminació de Programari Innecessari (Manteniment) Actualitzar el sistema Eliminar programari no utilitzat sudo apt update && sudo apt upgrade sudo apt autoremove Configuració del Tallafoc (Firewall) (Protecció de la Xarxa) El tallafoc és l’eina essencial per filtrar el trànsit de xarxa. Debian tradicionalment usava iptables però és comú utilitzar nftables o UFW (Uncomplicated Firewall) com a interfície simplificada. # Instal·lar sudo apt install ufw # Denegar tot per defecte sudo ufw default deny incoming # Permetre connexions SSH (Port 22) sudo ufw allow ssh # Activar el firewall sudo ufw enable Eines d’Auditoria i Monitorització Aquestes eines ajuden a supervisar i a registrar l’activitat. Audit Framework El Linux Audit Framework (amb el dimoni auditd) permet registrar un gran detall d’esdeveniments. sudo dnf install audit Configureu regles a /etc/audit/rules.d/audit.rules per monitoritzar accés a fitxers sensibles, execució de programes, etc Regles d’Auditoria Essencials Crea un fitxer de regles personalitzat; sudo vim /etc/audit/rules.d/custom.rules Regles recomanades per començar 2. Monitoritzar canvis en configuració sudo -w /etc/sudoers -p wa -k sudoers_changes -w /etc/sudoers.d/ -p wa -k sudoers_changes # 3. Monitoritzar canvis en configuració SSH -w /etc/ssh/sshd_config -p wa -k sshd_config # 4. Monitoritzar canvis en configuració de xarxa -w /etc/network/ -p wa -k network_changes -w /etc/sysconfig/network-scripts/ -p wa -k network_changes # 5. Monitoritzar ús de sudo -a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=-1 -k elevated_commands -a always,exit -F arch=b32 -S execve -F euid=0 -F auid>=1000 -F auid!=-1 -k elevated_commands Aplicar les Regles # Recarregar regles sudo augenrules –load # Reiniciar el servei sudo systemctl restart auditd # Verificar que les regles s'han carregat sudo auditctl -l Un cop carregades les regles correctament: sudo systemctl restart auditd # Verificar estat sudo systemctl status auditd Seguretat màquina Windows 2019 (AD) Selecció de l’Eina Les eines escollides milloren la detecció sense tocar l’esquema. Evita eines de tercers invasives que puguin requerir agents que interfereixin amb replicacions o autenticacions Kerberos.   Però, riscos: Eines mal configurades poden generar massa logs (sobrecàrrega de CPU/disk), interferir amb replicacions AD o causar inestabilitat si modifiquen components crítics com l’esquema AD. Per això, recomanem eines lleugeres, provar en un entorn de test si possible, i monitorar el rendiment del servidor (usant PerfMon o Task Manager). Utilitzades Polítiques d’Auditoria Avançada: Built-in en Windows, permet registrar esdeveniments específics sense instal·lacions addicionals. Sysmon (System Monitor): Eina gratuïta de Sysinternals per registrar activitats detallades com creacions de processos, connexions de xarxa i càrregues de drivers. És lleugera, però requereix configuració per evitar soroll excessiu. Visualitzador d’Esdeveniments (Event Viewer): Per revisar els logs generats. Seguretat a servidor SAMBA Configuració i activació d’UFW per Samba Troba el teu rang de xarxa local (per restringir l’accés només a la teva LAN, més segur) i permet Samba només des de la teva xarxa local: ip route | … Read more

SAI 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: Definir criteris realistes per seleccionar i implementar Sistemes d’Alimentació Ininterrompuda (SAIs) a l’empresa, prioritzant la continuïtat dels serveis crítics per permetre als treballadors seguir operant amb els seus portàtils durant apagades elèctriques. Aquesta versió assumeix que els elements no són màquines virtuals (VMs), sinó equips físics reals, i que els clients són portàtils de treballadors (~20 unitats amb bateries pròpies). Descripció de l’entorn del laboratori Topologia lògica principal: Torre DHCP + Firewall → Switch de 5 ports → 2 hosts físics amb VLANs separades. Equip crítics (connectats al SAI): Torre DHCP + FW: Intel Core i5-6400 (4 nuclis, baixa càrrega: 66.7% idle, ~0% user, 33.3% system). Switch: 5 ports. Servidors físics en una VLAN: 4 unitats separades (servidor de correu en Rocky Linux, servidor Samba en Debian, servidor Windows Server 2019 amb Active Directory, i servidor DNS en Debian). Aquests són equips físics independents, no VMs. Altres equips:  els ~20 clients són portàtils de treballadors (laptops amb bateries integrades). Escenari d’apagada Els servidors  han de romandre actius per mantenir serveis. Els treballadors podran seguir treballant amb els seus portàtils gràcies a les bateries pròpies (típicament 1-4 hores d’autonomia), mentre el SAI protegeix els servidors. No cal SAI per als portàtils, ja que són mòbils i no crítics per la xarxa. Criteris de selecció i ús de SAIs Potència requerida (VA/Watts): Mínim 2000-3000VA (1200-1800W) amb marge del 25-30% per pics, arrencades i creixement.  Temps de backup: Mínim 15-20 minuts a càrrega plena per permetre shutdown ordenat i transició. Amb low-load, buscar 30+ minuts per mantenir serveis actius mentre els treballadors continuen amb portàtils. Altres consideracions: Instal·lació: Només en equips crítics (torre, switch, 4 servidors físics). Els portàtils de treballadors no requereixen SAI, ja que les seves bateries permeten continuïtat breu. Escalabilitat: Models rack-mount si l’empresa creix (més servidors o treballadors). Manteniment: Revisió anual; bateries duren 3-5 anys.  Cost: <600-800€ inicial per model adequat; prioritzar relació qualitat-preu. Càlcul de potència requerida Torre DHCP+FW (i5-6400, baixa càrrega): 30-50W (idle ~40W en equips similars amb components bàsics). Switch 5 ports (sense PoE): 4-8W ( TP-Link). 4 Servidors físics (cadascun independent, low-load): Servidor correu (Rocky Linux): 80-150W. Servidor Samba (Debian): 80-150W. Servidor Windows 2019 AD: 100-200W (més consum per Windows). Servidor DNS (Debian): 80-150W. Subtotal servidors: 340-650W (mitjana ~500W). Total estimat idle/normal: 374-708W (mitjana ~550W). Amb marge 25-30% (per pics, arrencades, creixement): ~700-920W. Recomanació mínima: 2000VA / 1200W (cobreix amb seguretat). Si l’empresa afegeix més servidors, puja a 2500-3000VA.   Elecció recomanada: Eaton 5P 2200 (2200VA/1980W). Raons: Cobreix el consum ajustat amb ample marge per equips físics, ofereix temps suficient per mantenir serveis actius (permetent als treballadors amb portàtils continuar sense interrupció immediata), integra bé amb VLANs i serveis crítics, i és escalable per una empresa com Makrosoft. Preu raonable amb suport tècnic bo. Si el pressupost és limitat, optariem per CyberPower CP1500PFCLCD.   Implementació recomanada Connectar al SAI: Torre DHCP+FW, switch de 5 ports, i els 4 servidors físics (no incloure portàtils de treballadors). Configuració: Instal·lar software de gestió (ex.: Eaton IPP per shutdown automàtic en Windows/Linux). I configurar alerts via correu per baixa bateria. Procediment en apagada: el SAI manté servidors actius 15-20 min; els treballadors continuen amb portàtils (bateries pròpies) fins a restauració o shutdown ordenat. Monitoratge i manteniment: Ús de l’eina SNMP per vigilància remota; test mensual del SAI. Pressupost inicial estimat: 500-700€ (SAI + instal·lació bàsica). Cost anual: ~100-200€ en energia i bateries.

Compartició de claus SSH amb els companys Tornar al repte 2.2 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 de l’Hugo: Copiar al portàtil de l’Andres: Des del portatil de l’Hugo fem el mateix. Copiem la seva clau pública al portàtil de l’Andres i el meu. Des del portatil de l’Andres fem el mateix. Copiem la seva clau pública al portàtil de l’Hugo i el meu.

Compartició de claus SSH amb la passarel·la Tornar al repte 2.2 Objectiu Que tothom de l’equip actual pugui fer ssh usuari@172.25.203.12 sense posar contrasenya. Que ningú de fora de l’equip actual (ni equips anteriors) hi tingui accés. Genera o assegura’t que tens la teva clau SSH ssh-keygen -t ed25519 -C "nom_cognom@equip-actual" Copia la teva clau pública: Et demanarà la contrasenya actual una última vegada → la poses i ja està, la teva clau pública queda copiada automàticament a la torre. ssh-copy-id alumne@172.25.203.12 Amb el portàtil de l’Hugo: Amb el portàtil de l’Andres: 4. Netejar les claus antigues Quan confirmeu que tothom de l’equip actual ja entra sense contrasenya, un de l’equip entra a la torre i Dins la torre, edita el fitxer d’autorització (com a root o amb sudo):  sudo nano /home/alumne/.ssh/authorized_keys Esborra totes les línies excepte: Les claus públiques dels membres actuals de l’equip La clau del professorat

Creació d’una màquina virtual Windows Server 2019 Tornar al repte 2.1 Pas 0 — Baixar la ISO amb FileZilla Obre FileZilla i introdueix les credencials del servidor (Host, Username, Password i Port). Connecta’t i navega pel panell de la dreta fins a la carpeta on es troba la ISO de Windows Server 2019. Al panell de l’esquerra, tria la carpeta local on vols desar-la (ex.: /home/usuari/Descàrregues). Fes doble clic al fitxer ISO o arrossega’l de dreta a esquerra per iniciar la transferència. Espera fins que aparegui a la zona Successful transfers. Pas 1 — Crear la màquina virtual 1. Obre VirtualBox i fes clic a New per crear una nova MV. 2. Assigna nom (ex. W2019-repte1), tipus Microsoft Windows i versió Windows 2019 (64-bit). 3. Assigna memòria RAM (p. ex. 4096 MB) i crea un disc dur virtual VDI dinàmic (p. ex. 50 GB). Pas 2 — Afegir la ISO com a dispositiu d’arrencada Amb la MV apagada, entra a Settings → Storage. Afegeix (o selecciona) el controladora IDE/SATA i carrega la ISO descarregada (la vas treure amb FileZilla a la carpeta local /home/…). Pas 3 — Arrencada i pantalla inicial d’instal·lació Inicia la MV. Apareixerà la pantalla inicial de Windows Setup. Fes clic a Install now per començar. Pas 4 — Seleccionar idioma i format Tria Language to install, Time and currency format, i Keyboard segons les teves preferències. En aquest cas s’ha deixat English (United States) per a l’idioma d’instal·lació i Spanish com a format de data/hora si cal. 2. Fes clic a Next. Pas 5 — Acceptar termes de llicència i tipus d’instal·lació Marca la casella I accept the license terms i fes Next. Tria Custom: Install Windows only (advanced) per fer una instal·lació neta i poder crear particions. Pas 6 — Crear particions i instal·lar Al selector de discos crea la partició principal al disc virtual (o deixa que l’instal·lador la creï automàticament). Fes clic a Next; l’instal·lador començarà a copiar fitxers i a instal·lar. Pas 7 — Comprovar que la MV té Internet Un cop iniciat Windows Server 2019, entra al menú Start. Obre Command Prompt (cmd). Escriu ping 8.8.8.8 i prem Enter. Si reps respostes, tens connexió. També pots provar ping google.com per confirmar que funciona el DNS. Si no hi ha connexió, revisa a VirtualBox: Settings → Network Adapta Adapter 1 com NAT o Bridged Adapter segons necessitis.  

Investigació: Repte 2.2 – MAKROSOFT Tornar al repte 2.2 Laboratori de treball Infraestructura Pla de protecció Servei de directoris Unitat de xarxa configuració client Còpies totals, diferencials e incrementals Servidor de correu electrònic

Accés remot des de casa al portàtil de l’aula Tornar al repte 2.1 1. Crear i activar el meu compte He entrat a https://www.dwservice.net He fet Sign Up i he creat un compte. He fet Login amb el meu usuari. Configuració feta pel professor A la classe, el professor va fer aquests passos al portàtil de la classe:   El portàtil de classe no està al teu compte, està al compte del profe.Perquè tu el puguis veure, el profe ha ha de compartir-lo. Va vincular el portàtil al seu compte de DWService. Va anar a Recursos compartits (Shared Resources). Va compartir el portàtil de classe amb el meu compte. Ara jo tinc permís per accedir-hi des de casa. Com accedir des de casa Obro https://www.dwservice.net Faig Login amb el meu usuari. Entro a Recursos compartits (Shared Resources). Busco el portàtil de classe a la llista. Comprovo que estigui online. Clico Open. Selecciono Remote Desktop. Veig i puc usar la pantalla del portàtil de classe.

Pujada al cloud de vagrant de les boxes creades Tornar al repte 2.1 Error a l’inici de sessió de Vagrant i solució amb Google Drive Descripció del problema: Error: Quan vaig crear un compte al Vagrant Cloud i vaig intentar verificar-lo, no vaig rebre el correu de verificació. Això va impedir que pogués pujar la meva box a Vagrant Cloud, ja que el compte no estava verificat i no podia iniciar sessió correctament. No vaig rebre el correu de verificació a la meva bústia d’entrada. Tot i intentar reenviar l’email de verificació i revisar la carpeta de spam/junk, no vaig rebre cap correu. El procés de pujar la box a Vagrant Cloud es va veure bloquejat per l’inici de sessió. Solució aplicada: Degut a aquest problema, vaig optar per una solució alternativa per compartir la meva box de Vagrant sense necessitat d’utilitzar Vagrant Cloud: Passos per a la solució: Exportar la box de Vagrant: Primer, vaig exportar la box creada localment amb la comanda següent: vagrant package –output nom_box.box 2. Pujar la box a Google Drive: Vaig pujar el fitxer .box a Google Drive (podeu utilitzar qualsevol servei de núvol). Un cop pujat el fitxer, vaig obtenir l’enllaç públic per poder-lo compartir. Això ho vaig fer clicant amb el botó dret sobre el fitxer i seleccionant l’opció “Obtenir enllaç”. Vaig configurar els permisos perquè el fitxer fos públic i accessible a tothom amb l’enllaç. 3. Afegir la box a Vagrant: Amb l’enllaç de Google Drive, vaig afegir la box a Vagrant amb la següent comanda: vagrant box add nom_box "https://drive.google.com/uc?export=download&id=ID_DEL_FITXER" 4. Comprovar la box a Vagrant: Finalment, vaig comprovar que podia fer servir la box sense problemes amb la comanda: vagrant init nom_box -Després de seguir aquests passos, vaig poder afegir i fer servir la meva box de manera efectiva sense dependre del procés de verificació del correu a Vagrant Cloud. -La solució va permetre compartir les 5 boxes amb l’equip a través de Google Drive, i ara qualsevol membre de l’equip pot descarregar-les i utilitzar-les directament sense necessitat de mantenir l’enllaç de Drive o accedir a Vagrant Cloud. -A més, compartir les boxes amb l’equip mitjançant Google Drive permet un accés fàcil i ràpid, sense necessitat de gestionar enllaços de descàrrega cada vegada.