Aplicatii specifice

Instalare/reinstalare aplicatii default(Office, PDF reader) 11 Solutii

Instalare/Reinstalare aplicatii predefinite (ex. Office, PDF reader) 49 Solutii

Instalare/reinstalare aplicatii la cererea clientului 26 Solutii

Instalare/Dezinstalare aplicatii cerute de client (Viewer .p7m - caiet de sarcini, Autocad) 23 Solutii

Configurare browser 144 Solutii

Configurare program 2594 Solutii

Depanare Office 72 Solutii

Depanare alte aplicatii 40 Solutii

Configurarea Windows LAPS pentru rotirea automată a parolelor de administrator local

In multe retele, contul de administrator local are aceeasi parola pe toate statiile si serverele, sau o parola care nu se schimba niciodata. Daca un atacator afla acea parola de pe o singura masina, o poate folosi pentru a se deplasa lateral pe toate celelalte (lateral movement). Windows LAPS (Local Administrator Password Solution) rezolva asta: genereaza automat cate o parola unica si complexa pentru fiecare masina, o stocheaza criptat in Active Directory si o roteste periodic.

Spre deosebire de vechiul Microsoft LAPS (care necesita un client instalat separat), Windows LAPS este integrat nativ in sistemul de operare incepand cu actualizarile din 11 aprilie 2023 si mai noi.

Cerinte preliminare

  • Sisteme suportate: Windows Server 2019/2022/2025, Windows 10 22H2/21H2 si Windows 11, toate cu actualizarile din aprilie 2023 sau mai recente.
  • Domain Controllere la zi: rulati Windows Update pe TOATE controllerele de domeniu inainte de a extinde schema. Daca actualizati doar un DC, extinderea schemei va da eroare.
  • Nivel functional: Windows Server 2016 Domain/Forest Functional Level sau mai nou, necesar pentru criptarea parolelor in AD.
  • Permisiuni: cont membru al grupurilor Schema Admins si Enterprise Admins pentru extinderea schemei.

Pasul 1 — Extinderea schemei Active Directory

Pe un Domain Controller, deschideti PowerShell ca administrator si verificati mai intai ca modulul LAPS este disponibil:

Get-Command -Module LAPS

Daca nu apare niciun rezultat, sistemul nu este actualizat la o versiune suportata. Apoi extindeti schema:

Update-LapsADSchema -Verbose

Comanda va cere confirmarea. Apasati A (Yes to All) pentru a adauga toate atributele necesare. Parametrul -Verbose afiseaza detalii despre operatiune.

Pasul 2 — Acordarea permisiunilor pe unitatea organizatorica (OU)

Acordati computerelor dreptul de a-si scrie singure parola in AD. Rulati comanda pe OU-ul care contine statiile/serverele gestionate:

Set-LapsADComputerSelfPermission `

-Identity “OU=Workstations,DC=firma,DC=local”

Optional, restrictionati cine poate citi parola (doar administratorii IT, nu utilizatorii obisnuiti):

Set-LapsADReadPasswordPermission `

-Identity “OU=Workstations,DC=firma,DC=local” `

-AllowedPrincipals “IT_Admins”

Pasul 3 — Configurarea politicii prin Group Policy

Deschideti Group Policy Management, creati un GPO nou legat de OU-ul dorit si navigati la:

Computer Configuration > Policies > Administrative Templates > System > LAPS

Setari recomandate:

  • Configure password backup directory: Enabled → setati pe Active Directory.
  • Enable password encryption: Enabled (necesita nivel functional 2016+).
  • Name of administrator account to manage: Enabled → introduceti numele contului local de administrator gestionat (ex. lapsadmin).
  • Password Settings: configurati lungimea (ex. 20 de caractere), complexitatea si varsta maxima a parolei (ex. 30 de zile).
  • Do not allow password expiration time longer than required by policy:

Pasul 4 — Aplicarea si verificarea

Pe statiile client, fortati actualizarea politicii si repornirea gestionarii:

gpupdate /force

Pentru a verifica din PowerShell parola stocata a unei masini (rulat cu un cont care are drept de citire):

Get-LapsADPassword -Identity “STATIE01” -AsPlainText

Verificati evenimentele LAPS pe client in Event Viewer:

Applications and Services Logs > Microsoft > Windows > LAPS > Operational

Cautati Event ID 10018 — „Password successfully updated in AD”. Puteti verifica si atributul msLAPS-PasswordExpirationTime pe obiectul computerului, sau folosi tab-ul LAPS din Active Directory Users and Computers (necesita RSAT).

[mai mult...]

Diagnosticarea și rezolvarea erorii „Kernel panic – not syncing: Attempted to kill init!”

1. Introducere și definirea erorii

Eroarea Kernel panic - not syncing: Attempted to kill init! reprezintă o stare critică de eroare neremediabilă în sistemele de operare Linux. În această stare, nucleul (kernel-ul) oprește complet executarea oricărei instrucțiuni pentru a preveni coruperea datelor sau deteriorarea fizică a sistemului de fișiere.

Mesajul indică direct faptul că primul proces lansat de kernel la pornirea sistemului (procesul cu PID 1, numit init sau systemd) a fost oprit neașteptat sau a fost terminat forțat (killed). Deoarece procesul init este „părintele” tuturor celorlalte procese din sistem, oprirea lui face imposibilă funcționarea în continuare a sistemului de operare.

2. Cauzele principale ale erorii

Defectarea sau prăbușirea procesului init are loc, în general, în prima fază de boot (încărcare) a sistemului și este cauzată de următoarele categorii de probleme:

A. Coruperea sau lipsa imaginii initramfs / initrd

Imaginea Initial RAM Disk (initramfs) conține driverele și modulele necesare kernelului pentru a putea citi și monta discul principal. Dacă această imagine este coruptă, lipsă sau a fost generată greșit după o actualizare de kernel, sistemul nu poate lansa init.

B. Probleme legate de configurarea Bootloader-ului (GRUB)

  • Anumiți parametri de boot din configurarea GRUB trimit kernelul către un disc greșit (ex: o adresă root=UUID=... incorectă).

  • Parametrul init= arată către o cale inexistentă (ex: /sbin/init lipsește sau este corupt).

C. Coruperea sistemului de fișiere sau a discului (Filesystem / Hardware)

  • Sector defect pe disc (SSD/HDD) în zona unde se află executabilul /sbin/init sau /lib/systemd/systemd.

  • Corupere cauzată de o oprire necorespunzătoare a alimentării cu energie electrică.

D. Lipsa spațiului pe disc în timpul actualizărilor (/boot plin)

O cauză extrem de frecventă pe servere și calculatoare de birou este umplerea partiției /boot. Dacă la un update de sistem (apt upgrade / dnf update) discul este $100\%$ plin, noul kernel sau imaginea initramfs se va scrie parțial, rezultând o imagine invalidă la următorul restart.

E. Neconcordanță între arhitectura sistemului și module

Executarea unui kernel pe $64$ de biți cu un proces init compilat pentru o altă arhitectură necompatibilă sau din cauza unor permisiuni de fișiere alterate (/sbin/init și-a pierdut drepturile de execuție chmod +x).

3. Ghid 

Când întâmpinați această eroare, sistemul nu mai poate porni normal. Rezolvarea necesită intervenția prin mediul de recuperare (GRUB sau un Live USB).

Pasul 1: Pornirea dintr-o versiune anterioară de Kernel (Meniul GRUB)

Aceasta este cea mai rapidă metodă de testare și recuperare:

  1. Reporniți sistemul și țineți apăsată tasta Shift sau Esc pentru a afișa meniul GRUB.

  2. Selectați Advanced options for Ubuntu/Debian/RHEL.

  3. Alegeți o versiune anterioară de kernel (de exemplu, o versiune mai veche care nu are eticheta recovery mode).

  4. Dacă sistemul pornește cu succes, problema este legată strict de ultimul kernel instalat sau de imaginea sa initramfs.

Pasul 2: Regenerarea imaginii initramfs

Dacă ați reușit să intrați într-un kernel vechi sau folosind un Live USB (prin metoda chroot), regenerați fișierele de boot:

  • Pe sisteme bazate pe Debian / Ubuntu:

    Bash

    sudo update-initramfs -u -k all
sudo update-grub

  • Pe sisteme bazate pe RHEL / CentOS / Fedora:

    Bash

    sudo dracut --regeneration --force
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Pasul 3: Repararea sistemului de fișiere (fsck)

Dacă eroarea este provocată de un disc corupt:

  1. Porniti dintr-un Live USB/CD de Linux.

  2. Deschideți un terminal și identificați partiția de sistem (ex: /dev/sda1 sau /dev/nvme0n1p2) cu comanda lsblk.

  3. Rulați verificarea și repararea partiției:

    Bash

    sudo fsck -y /dev/sda1

Pasul 4: Curățarea spațiului din partiția /boot

Dacă partiția /boot este plină și a blocat actualizarea:

  1. Porniți din Live USB și montati partiția de sistem.

  2. Ștergeți kernel-urile vechi nefuncționale sau fișierele temporare nefinalizate din /boot.

  3. Rulați comanda de curățare a pachetelor incomplete:

    Bash

    # Dintr-un mediu chroot:
apt-get clean
apt-get autoremove
dpkg --configure -a

4. Măsuri de prevenție

  • Evitați umplerea partiției /boot: Configurați sistemul să păstreze doar 2-3 imagini de kernel (utilizați opțiuni de curățare automată precum Purgeremovedupes sau installonly_limit în managerul de pachete).

  • Nu opriți forțat calculatorul în timpul actualizărilor: Închiderea alimentării în timp ce se execută comenzi de tip update-initramfs sau dracut va deteriora garantat fișierele de boot.

  • Folosiți surse de alimentare neîntreruptibile (UPS): Pe servere de producție, întreruperile bruște de curent sunt principala cauză a coruperii procesului init și a sistemului de fișiere.

[mai mult...]

Diagnosticarea și rezolvarea erorii „Bus error (core dumped)” în Linux

1. Introducere și definirea erorii

Eroarea Bus error (core dumped) este generată în sistemele de operare de tip Unix/Linux atunci când procesorul (CPU) încearcă să acceseze o adresă de memorie RAM la care hardware-ul nu poate efectua o citire sau o scriere fizică.

Din punct de vedere al sistemului de operare, această eroare corespunde semnalului SIGBUS (Semnalul cu numărul 7). Când kernelul Linux trimite acest semnal unui proces, aplicația este oprită forțat, iar sistemul creează un fișier numit core dump (o imagine a stării memoriei din momentul prăbușirii) pentru analiză ulterioară.

2. Cauzele principale ale erorii SIGBUS

Spre deosebire de Segmentation Fault (SIGSEGV) — care apare când un program încearcă să acceseze memorie nealocată sau nepermisă din punct de vedere software —, Bus Error (SIGBUS) indică aproape întotdeauna o problemă de aliniere fizică, de acces la hardware sau de stocare/fișiere mapate.

Cele mai frecvente cauze sunt:

  1. Probleme de aliniere a memoriei (Memory Alignment Error):

    • Apare pe arhitecturi CPU mai stricte (cum ar fi ARM, SPARC) sau pe arhitecturi x86 în cazul instrucțiunilor vectoriale (AVX/SSE).

    • Se întâmplă când procesorul încearcă să citească un tip de date (de exemplu, un întreg pe 4 sau 8 octeți) de la o adresă de memorie care nu este divizibilă cu dimensiunea acelui tip de date.

  2. Eroare la fișierele mapate în memorie (mmap):

    • Dacă o aplicație folosește funcția mmap() pentru a încărca un fișier direct în memorie, iar fișierul de pe disc este trunchiat, șters sau devine inaccesibil în timp ce procesul încearcă să îl citească/scrie.

  3. Erori de citire/scriere fizică I/O (Disk / Hardware Failure):

    • Sector defect pe hard disk/SSD pe care se află fișierul de swap sau aplicația executată.

    • Probleme legate de rețea dacă se folosește un sistem de fișiere de rețea (NFS, SMB) care își pierde conexiunea la fișierul mapat.

  4. Instrucțiuni hardware defectuoase (Defecțiuni RAM):

    • Module de memorie RAM fizic defecte sau setări incorecte în BIOS (XMP/overclock instabil).

3. Ghid pas cu pas pentru rezolvare și diagnosticare

Pasul 1: Identificarea rapidă a fișierelor mapate și spațiului pe disc

Dacă eroarea apare la rularea unui program standard sau a unui utilitar de sistem (ex: python, node, un utilitar din rețea):

  • Verifică spațiul pe disc: Rulează df -h. Dacă disk-ul este plin ($100\%$), scrierile pe fișiere mmap pot eșua cu SIGBUS.

  • Verifică mount-urile de rețea: Dacă rulezi un script peste NFS sau un drive de rețea, asigură-te că conexiunea este stabilă.

Pasul 2: Analiza fișierului Core Dump cu gdb

Pentru a găsi linia exactă de cod din cauza căreia s-a prăbușit aplicația:

  1. Activați crearea fișierelor core dump în terminal:

    Bash

    ulimit -c unlimited

  2. Rulați din nou aplicația pentru a genera fișierul core.

  3. Deschideți fișierul core cu debugger-ul GNU (gdb):

    Bash

    gdb ./nume_executabil core

  4. În consola gdb, tastați comanda bt (backtrace) pentru a vedea funcția și linia exactă unde s-a emis semnalul SIGBUS.

Pasul 3: Rularea sub valgrind (pentru dezvoltatori)

Dacă analizați propriul cod (C/C++), valgrind poate detecta accesul nealiniat sau pointerii invalizi:

Bash

valgrind --tool=memcheck ./nume_executabil

Pasul 4: Testarea memoriei RAM (Hardware)

Dacă eroarea apare aleatoriu în diverse programe care funcționau normal în trecut, cauza poate fi hardware:

  • Verificați logurile kernelului cu comanda:

    Bash

    dmesg -T | grep -iE "memory|error|ecc|mce"

  • Rulați un test dedicat de memorie: MemTest86 sau utilitarul memtester direct din Linux.

4. Cum se previne Bus Error în Codul Sursă (C / C++)

Dacă sunteți dezvoltator software, iată cele mai bune practici pentru a evita SIGBUS:

  • Respectați alinierea structurilor: Nu folosiți casting direct de la un pointer de tip char* (1 byte) la un pointer de tip uint64_t* (8 bytes) fără să verificați alinierea adresei.

  • Folosiți directiva alignas (C++11/C11):

    C++

    alignas(8) char buffer[64]; // Garantează alinierea la 8 octeți

  • Tratarea corectă a apelului mmap: Când lucrați cu mmap, verificați întotdeauna dimensiunea fișierului folosind fstat() înainte de acces și capturați semnalul SIGBUS folosind sigaction().

[mai mult...]

How to use claude to build automations in Excel

AI promises to make tedious work easier, but I wanted to know whether it could deliver in real Excel projects. Rather than asking Claude for formulas or snippets of code, I tested whether it could handle three types of automation: creating a workbook from scratch, building a reusable reporting system, and developing a tool that analyzes existing spreadsheets. The goal was to see how much of the work Claude could handle and where I would still need to step in.

[mai mult...]