标签：#UX

When something breaks in Linux, experienced engineers don’t guess. They check the logs. 👉 Logs are the “black box recorder” of a Linux system. They tell you: what happened when it happened why it failed If you can read logs properly, you can debug almost anything. What Are Logs? Logs are records of system and application activity. Linux constantly records: System events Errors User activity Application behavior Linux constantly records: Where are Logs Stored? Most Linux logs are stored inside: /var/log Check logs directory: cd /var/log ls This is the first place DevOps engineers check during system issues. Important Log Files Log File Purpose Command to View /var/log/syslog General system messages tail /var/log/syslog /var/log/auth.log Login attempts & authentication tail /var/log/auth.log /var/log/kern.log Kernel & hardware messages dmesg or tail /var/log/kern.log /var/log/nginx/error.log Web server errors (Nginx) tail /var/log/nginx/error.log /var/log/dmesg Boot and hardware logs dmesg /var/log/apache2/ -> Apache logs These logs help you identify system, security, and application-level issues. View Logs Using cat cat /var/log/syslog Good for small files. Using less less /var/log/syslog Useful keys:: Space → Next page b → Previous page q → Quit 👉 Best for large log files. Using tail tail /var/log/syslog Show last 10 lines. Real-Time Monitoring (tail -f) tail -f /var/log/syslog 👉 -f = follow live updates This is one of the most-used debugging commands in production servers. Stop with: Ctrl + C Searching Logs with grep grep error /var/log/syslog Case-insensitive: grep -i failed /var/log/auth.log Show latest matching errors: grep error /var/log/syslog | tail -n 50 👉 Essential for filtering huge logs quickly. Boot & Hardware Logs (dmesg) dmesg Shows: Boot messages Hardware detection Kernel events Useful for startup and hardware troubleshooting. Modern Log System: journalctl Modern Linux systems use systemd logs . journalctl Recent errors: journalctl -xe Specific servic

Overview Tulisan ini menceritakan pengalaman saya meng-install NixOS di VPS Jetorbit memakai nixos-anywhere , dideploy dari laptop macOS (nix-darwin). Komposisi Laptop (macOS + nix-darwin) : Semua konfigurasi NixOS dibuat di sini, lalu dikirim ke server. VPS Jetorbit (x86_64 Linux) : target deploy. Boot lewat legacy BIOS , dengan IP statis (bukan DHCP). nixos-anywhere : dipakai sekali saja untuk install awal. nixos-rebuild : dipakai untuk update konfigurasi setelah install awal. Catatan Penting : VPS tidak perlu menyimpan file konfigurasi sendiri. Kita edit config di laptop, lalu push ke VPS lewat SSH. Tidak ada apt update , tidak ada config drift, dan kondisi server selalu reproducible dari git. Pre-flight: Cek Sebelum Menyentuh Server Banyak kegagalan install sebenarnya bisa dicegah kalau kita cek tiga hal ini: 1. Mode boot: UEFI atau legacy BIOS? Ini menentukan konfigurasi bootloader. Salah konfigurasi di sini dapat menyebabkan GRUB gagal saan install nanti. Di VPS (SSH ke VPS): [ -d /sys/firmware/efi ] && echo "UEFI" || echo "BIOS" Di Jetorbit secara default adalah BIOS . Artinya konfigurasi GRUB mode legacy BIOS, bukan EFI. 2. Networking: IP, netmask, dan gateway Jetorbit memakai IP statis, bukan DHCP. Kalau konfigurasi NixOS kita set IP maka NixOS akan fallback ke DHCP, dan akan gagal dapat IP, sehingga server jadi tidak bisa diakses sama sekali setelah reboot. Di VPS: ip -4 a # lihat IP + CIDR dan nama interface (misal. ens3) ip route # lihat "default via X.X.X.X", itu gateway-nya Contoh: 2: ens3: ... inet 110.XXX.XXX.XXX/24 brd 110.XXX.XXX.255 scope global ens3 3. SSH Root nixos-anywhere memerlukan akses root ke server untuk bisa melakukan instalasi. Akses ini didapat lewat SSH key, bukan password. Jadi pastikan Di VPS: public key sudah terdaftar di root . Konfigurasi SSH root ini bisa dilakukan saat install OS awal di panel Jetorbit atau dikonfigurasi secara manual di ~/.ssh/authorized_keys . Cara Kerja nixos-anywhere Sebelum menjalankan perintahnya, ada ba

Aprenda a substituir o velho Cron por systemd timers para ganhar logs nativos, controle de dependências e maior robustez.

I am committed to understand how systems actually work. I'm working on a multi-node lab to follow the complete path of a request from Python APIs to Linux processes, through Docker containers, networking and observability. The idea is simple: build a system that observes another system to understand the abstraction layers behind modern infrastructure. This project is about learning by building, experimenting and understanding what happens under the hood. Link: [ https://github.com/daniloprandi/devops-network-automation-lab ] DevOps #Linux #Python #Docker #Networking #Observability #Infrastructure

TeamLab 那片會跟著你走的花海，原理拆解＋DIY 先看這張圖 這是 TeamLab 在東京台場的《呼應燈之森林》。當你走過去，附近的燈會慢慢亮起；你離開後，燈又慢慢暗下去，像是真的森林一樣。 還有另一個作品《花與人的共存》，花叢會跟著你移動——你站的地方，花就開在你腳邊；你離開，花就凋謝。 這兩件作品的核心邏輯是一樣的。這篇文章就來拆解它。 原理一：偵測位置 TeamLab 的互動裝置需要知道「你在哪裡」。 最常見的方法有兩種： 紅外線感應 ：在地面下方埋紅外線接收器，你走過時阻擋光線，系統就知道有人在這個位置。缺點是只能測「有沒有人」，不能測「人在哪一個方向」。 深度相機（RealSense / Kinect） ：像 Xbox 的體感相機，透過紅外線測量每一個點到你相機的距離，生成一張「深度地圖」。軟體在深度地圖裡找出人體的位置，然後算出座標。 DIY 版本 ：一塊 Arduino + 超音波感測器（HC-SR04，大約 60 元）就能做到基本的「有人靠近」偵測。 原理二：控制回應 知道你在哪裡之後，系統要決定「要做什麼回應」。 TeamLab 的做法是 ：不是「觸發」，而是「強度變化」 。 傳統的感應燈：感應到人 → 燈全亮 → 人離開 → 燈全滅。 TeamLab 的邏輯：感應到人 → 燈慢慢變亮（0.5 秒）→ 人持續在 → 維持亮度 → 人離開 → 慢慢變暗（2 秒）。 「慢慢」是關鍵。瞬間變化讓人注意到「科技」；緩慢變化讓人以為「這個空間有生命」。 這就是「驚奇設計」的核心： 時機對了，物理反應看起來像生物反應。 原理三：集體行為 最後一個秘密：TeamLab 的裝置很少只有一個「回應」。 通常會有 100-500 個元素（燈、花、光點）。每個元素各自計算自己與你的距離，決定自己的亮度或顏色。 當 500 個燈各自以稍微不同的速度亮起和暗下，你看到的不是「一個燈亮了」，而是「一片森林在你腳下呼吸」。 心理錯覺 ：你把「一群各自輕微不同步的簡單反應」，詮釋成「一個整體有意志的生物」。 用 Arduino 自己做一個迷你版 材料： Arduino Uno（大約 200 元） 超音波感測器 HC-SR04（大約 60 元） LED 燈 x 3（大約 15 元） 麵包板和杜邦線 原理很簡單： 超音波感測器偵測距離 距離越近，LED 越亮（用 PWM 訊號控制） 距離越遠，LED 越暗 int trig = 7 ; int echo = 6 ; int led = 9 ; void setup () { Serial . begin ( 9600 ); pinMode ( trig , OUTPUT ); pinMode ( echo , INPUT ); pinMode ( led , OUTPUT ); } void loop () { digitalWrite ( trig , LOW ); delayMicroseconds ( 2 ); digitalWrite ( trig , HIGH ); delayMicroseconds ( 10 ); digitalWrite ( trig , LOW ); long duration = pulseIn ( echo , HIGH ); long distance = duration * 0.034 / 2 ; // 距離越近，LED 越亮 int brightness = map ( distance , 0 , 100 , 255 , 0 ); brightness = constrain ( brightness , 0 , 255 ); analogWrite ( led , brightness ); delay ( 50 ); } 這不是 TeamLab，但這是你自己做的「會呼吸的燈」。每個 maker 都是從這裡開始的。 庭庭：這個看起來很難 真的沒有你想的那麼難。 需要的東西全部可以在蝦皮買到，全部加起來大約 300 元。網路上有超多 Arduino 教學，關鍵字搜「Arduino 超音波 LED」就有幾十篇中文教學。 你不需要懂電子，只需要跟著步驟做，做完會有「哇，我自己做出了一個會亮的東西」的感動。 如果你想更進一步 TeamLab 的進入門檻其實不是技術，是「你要把技術藏在美學後面」。 推薦兩個方向可以繼續研究： p5.js + webcam ：用 p5.js 讀取你的 webcam 影像，偵測顏色或移動。相當於用軟體做到 Kinect 的效果，零硬體成本。 Processing + 投影機 ：把電腦畫面投射到牆上或地面上，加上感測器，就是一個簡單版互動投影。投影機在蝦皮一兩千元就有。 今日概念 ：TeamLab 的魔法不是魔法，是三個原

為什麼那個會「注意你」的展品，反而讓你更想靠近 博物館互動設計的隱形槓桿 東京。 teamLab 展覽入口。 地面是一整片黑色的水面，倒映著數位花朵。 你踏進去。 花朵在你腳步周圍散開，隨著你的移動一圈一圈地綻放和飄落。 你停下來，花也停下來。 你開始走，花就跟著你。 你以為是感應。但仔細看——延遲了大概 0.3 秒。 不是「立刻反應」，是「好像在觀察你，然後才決定」。 你站在那裡又多看了三秒。 你第一個「對」 讓我問你一個問題。 你去過那種「互動博物館」嗎？牆上寫著「請觸摸」，但你碰了之後什麼都沒發生——或者是那種「語音導覽機」，你對著它說話，它說「請靠近一點」。 然後你就失去興趣了。 現在讓我想另一個場景。 一個會動的恐龍骨骼。你站在它面前的時候，它頭轉過來看了你一眼。 你知道這是感應器。你知道工程師設計了「檢測到人」的時候讓它轉頭。 但你還是覺得—— 「它在看我。」 兩種互動，哪一個讓你停留更久？ 你第一個「咦」 這裡有一個秘密。 讓人停留更久的，通常不是「立刻反應」的互動。 是那種「 好像在決定要不要理你 」的互動。 為什麼？ 因為「立刻反應」讓你確認了——「這是機器」。 但「好像在決定要不要理你」讓你的大腦進入了一個不確定的狀態—— 「它真的知道我來了嗎？」 「它在決定什麼？」 「我想看看它決定什麼。」 這個「我想看看」就是互動設計裡最重要的瞬間—— 參與者的好奇心，被啟動了。 玉樹真一郎在《任天堂的體驗設計》裡，分析了一個現象： 《超級馬里奧》裡，當玩家靠近一個問號磚塊，頂了它，沒有任何東西掉下來。 玩家不會覺得「這個遊戲壞了」。 玩家會想：「 為什麼這次沒有？ 」 然後再頂一次。 為什麼「沒有東西掉下來」沒有讓玩家放棄？ 因為設計師在玩家心裡創造了一個「 還沒發生的確定事件 」。 玩家知道「遲早會有東西掉下來」。所以他們願意等待、願意再試一次。 博物館的互動設計也應該這樣。 不是立刻給答案。是讓你相信「答案快來了」，然後讓你一直站在那裡等。 你最後「我要改變做法」 讓我說一個失敗的設計。 一個科技博物館有一面「觸控牆」。牆上有很多按鈕，碰了就會播放影片、發出聲音、變色。 一開始很多小孩去碰。 但大概十五分鐘之後，那面牆就沒人碰了。 為什麼？ 因為碰了 100 次，沒有任何一次比另一次更「值得等待」。 每一次都是立刻發生，每一次都是同樣的結果。 沒有任何一件事需要「決定」。 現在讓我說一個成功的設計。 同一個博物館的另一區，有一面「情緒牆」。 你站在牆前，系統會掃描你的臉——不是真的分析情緒，而是給你一個顏色。 每個人的顏色都不太一樣。 但顏色不是立刻出現的。 大概等了兩秒——然後它慢慢浮現出來。 在這兩秒裡，每個站在牆前的人都沒有動。 他們在等。 他們相信顏色一定會出現。但他們不確定會是什麼顏色。 三個馬上可以用的方向 第一：不要立刻給回饋。 加入一個 0.3 到 2 秒的「思考時間」。 讓互動看起來像「系統在決定」，而不只是「系統在檢測」。 壞掉的燈 vs 正在決定的燈——後者讓人更想站在那裡等。 自己試試看：30 行做出「延遲反應」的燈 // p5.js — 試試延遲回饋的感覺 let lights = []; const DELAY = 12 ; // 幀數延遲（約 0.2 秒） function setup () { createCanvas ( 400 , 400 ); for ( let i = 0 ; i < 5 ; i ++ ) { lights . push ({ history : [], lit : false }); for ( let j = 0 ; j < Math . max ( DELAY , 1 ); j ++ ) lights [ i ]. history . push ( false ); } } function draw () { background ( 30 ); let hovered = floor ( mouseX / 80 ); for ( let i = 0 ; i < lights . length ; i ++ ) { lights [ i ]. history . push ( hovered === i ); if ( DELAY > 0 ) lights [ i ]. history . shift (); lights [ i ]. lit = DELAY > 0 ? lights [ i ]. history [ 0 ] : ( hovered === i ); } // 畫燈泡 noStroke (); for ( let i = 0 ; i < lights . length ; i ++ ) { fill ( lights [ i ].

AI can now scan major open-source projects and surface a batch of real, exploitable vulnerabilities in a single pass. That's a defensive win — until you remember attackers have the same tools. Anthropic, Google, Microsoft, OpenAI, AWS, and 15 other organizations aren't waiting for that race to get worse. On Thursday they launched Akrites under the Linux Foundation — a coordinated body built specifically for AI-era vulnerability discovery, remediation, and disclosure in critical open-source software. What actually changed A shared Security Incident Response Team (SIRT) replaces the fragmented model where multiple orgs independently scan the same libraries, file duplicate CVEs, and bury maintainers in noise Patch first, publish second — findings are held under strict confidentiality until a fix is ready and tested Fallback maintainer coverage — if a project has no active maintainer, Akrites steps in so fixes still reach downstream users Funded by Alpha-Omega , an OpenSSF project with $7M+ annual budget backed by the same founding members Three membership tiers — Premier (critical infra operators), General (contributing orgs), Associate (OSS foundations, free) The name comes from the Akritai — Byzantine soldiers who guarded the empire's outermost borders. The places most exposed, most frequently attacked, and most dependent on whoever showed up to defend them. The problem it's actually solving The current coordinated disclosure model was designed around a world where finding vulnerabilities took weeks of expert work. AI has collapsed that timeline. Endor Labs CEO Varun Badhwar put a number on it: thousands of validated open-source vulns surfaced by AI in recent months, with fewer than 5% patched. And the old model makes it worse — every org independently sitting on knowledge of an unpatched flaw is another leak risk before a fix exists. "For years, we have believed finding vulnerabilities was never the hard part. Fixing them was. AI has made that gap impossible to igno

People complain that websites are all starting to look the same. They are not entirely wrong. A lot of modern websites do look alike. They have familiar navigation bars, predictable layouts, large hero sections, cards, and responsive grids. Buttons look like buttons. Forms look like forms. But, I would argue that's a good thing. Software is supposed to feel familiar. A website is not a painting. It is not a brand mood board. A website is usually a tool that someone is trying to use to accomplish something. They want to read, buy, search, compare, book, or solve a problem. And when people are trying to get something done, originality is not always a virtue. Familiarity Is a Feature Jakob's Law says: Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know. Users do not arrive at your website as blank slates. They bring expectations from every other website and app they have used. They expect the logo to link home. They expect navigation to be near the top or side. They expect search to look like search. They expect account settings under an avatar or profile menu. They expect mobile navigation to collapse into a menu. When your site follows those expectations, users can spend their mental energy on the task instead of the interface. That is the point. Good design reduces cognitive load. It does not force users to relearn basic interaction patterns just because a company wanted to look different. Different Is Not Automatically Better There is a common mistake in web design: confusing distinctiveness with quality. A site can be visually unique and still be frustrating to use. It can win design awards while annoying the actual people who need to navigate it. Novelty has a cost. Every unusual layout, hidden interaction, custom scroll behavior, strange menu, or clever visual metaphor asks the user to stop and figure out what is going on. If you are building a portfolio, an art proje

nginx Event Loop — Complete Lifecycle Reference A precise, bottom-up reference covering every buffer, syscall, interrupt, and data movement from the moment a TCP packet hits the NIC to the moment a response is sent back. Two concurrent users are used throughout as a concrete example. Table of Contents Foundations — fd and Socket Hardware Layer — NIC, DMA, Interrupts Kernel Structures and All Buffers epoll — How the Worker Waits Efficiently nginx Startup Sequence Complete Request Lifecycle — Two Concurrent Users What Happens While Worker is Busy All Buffers — Master Reference All Syscalls — Master Reference Failure Modes 1. Foundations 1.1 Everything is a File Linux's core philosophy: every I/O resource — files on disk, network connections, pipes, terminals, devices — is represented as a file. This means one unified API ( read , write , close ) works on all of them. The kernel manages the actual resource. Your process holds a token. 1.2 File Descriptor (fd) A file descriptor is just an integer . It is a per-process token that refers to a kernel-managed resource. The kernel maintains a table per process called the fd table — a simple array where the index is the fd and the value is a pointer into the kernel. Process fd table: ┌─────┬───────────────────────────────┐ │ fd │ points to │ ├─────┼───────────────────────────────┤ │ 0 │ stdin │ │ 1 │ stdout │ │ 2 │ stderr │ │ 3 │ listen socket (nginx) │ │ 5 │ User A client connection │ │ 6 │ User B client connection │ │ 12 │ backend connection for User A │ │ 13 │ backend connection for User B │ └─────┴───────────────────────────────┘ 0, 1, 2 are always pre-assigned. Application fds start from 3 upward. The fd is meaningless on its own. It only means something when passed to a syscall — the kernel uses it to look up the real resource. 1.3 Socket A socket is the kernel's internal data structure representing one end of a network connection. Created when your process calls socket() . Lives entirely in kernel RAM. Your process nev

Research Context "In advanced network observability, understanding the default behavior of various operating systems is vital for traffic profiling. This article explores the structural differences in ICMP Echo Requests across different OS environments and analyzes how 'Traffic Mimicry' can be used to evaluate the accuracy of Network Intrusion Detection Systems (NIDS)." 1. The Anatomy of an ICMP Signature A standard ICMP Echo Request is not just a simple signal; it carries a specific "fingerprint" based on the operating system that generated it. These fingerprints consist of: Total Packet Size TTL (Time to Live) values Default Payload Content 2. Cross-Platform Discrepancies (Linux vs. Windows) When a system sends a "ping," the default data size ($D$) and the total packet length ($L$) vary significantly between architectures. Feature Linux (Typical) Windows (Typical) Data Size ($D$) 56 Bytes 32 Bytes ICMP Header ($H$) 8 Bytes 8 Bytes Total ICMP Length ($L$) 64 Bytes 40 Bytes Default Payload Timestamp + Data abcdefg... The Linux Signature In most Linux distributions, the ping utility sends 56 bytes of data. When combined with the 8-byte ICMP header, it totals 64 bytes. A key characteristic of Linux ICMP traffic is that the first few bytes of the payload are often occupied by a high-resolution timestamp, used to calculate RTT (Round Trip Time) with microsecond precision. The Windows Signature Windows systems default to a 32-byte data payload. The payload content is static and follows a predictable alphabetical sequence: abcdefghijklmnopqrstuvwabcdefghi. This static nature makes Windows ICMP traffic easily identifiable during deep packet inspection (DPI). 3. The Concept of Traffic Mimicry Traffic Mimicry is a research method used to test the resilience of network filters. By aligning custom communication protocols with the default signatures of a specific OS, researchers can evaluate whether a security appliance is biased toward certain traffic patterns. For example, wh

Research Context When doing low-level network programming in Assembly, you experience firsthand the immense chaos running behind the scenes of operations we solve with a single line in high-level languages (Python, C, etc.). While developing the Nested-ICMP-Communication Analysis project, specifically an Encapsulated ICMP framework, I hit exactly this kind of wall: extracting an IP address from a packet header and printing it to the screen in the correct format. Sounds simple, right? However, when x86 architecture and network protocols are involved, seeing 5.1.168.192 instead of 192.168.1.5 on your terminal is extremely common. So why does this happen, and what kind of algorithm did I develop to overcome this issue during the debugging process? Let's dive into the background. The Endianness Problem in Network Headers When you capture a packet coming over the network and read the source/destination IP address inside the sockaddr_in structure, the data arrives in Network Byte Order (Big-Endian) format. This means the most significant byte is stored at the lowest memory address. However, the x86/x64 processor architectures we use rely on Little-Endian (Host Byte Order). When the processor pulls this 4-byte IP data into a register, the reading direction is effectively reversed for our purposes. The result? A packet that arrives as 192.168.1.5 appears scrambled if we try to naively print it from memory. The inet_ntoa() function in high-level languages handles this conversion in the background. But if you are writing a custom sniffer in pure Assembly, you must do this conversion byte by byte yourself. Debugging Hell: The Problems Encountered While writing this conversion, I encountered a few critical issues that cost me hours in GDB (GNU Debugger): Register Clashes: While separating each octet (byte) of the IP address and converting it to an ASCII character (string), you must use the AX register for division operations (DIV). If you don't carefully manage your remainders

After several years carrying a beta tag, the Kubernetes Security Profiles Operator went 1.0.0 on June 26, freezing eight CRD APIs and clearing a third-party security audit with no criticals. For cluster admins, the practical effect is small but consequential: the syscall and LSM profile a workload runs under is now declared on APIs that will not move under your feet. The release was announced by Sascha Grunert of Red Hat on the CNCF blog. SPO is the Kubernetes operator that manages seccomp, SELinux and AppArmor profiles as cluster-scoped objects, then attaches them to pods. Until now the value proposition was good and the API was provisional. v1.0.0 nails the second half down. What's actually stable All eight CRDs graduated to v1, including SeccompProfile , ProfileRecording , SelinuxProfile , RawSelinuxProfile , and the AppArmor profile type. Conversion webhooks ship with the release, so a cluster running earlier API versions can roll forward without scheduling downtime. The older versions remain available and are slated for removal in a future release. The migration is on the clock, not on fire. The audit pass came with some shape changes that are worth reading before you upgrade. SelinuxProfile swapped its boolean permissive field for a mode enum with Enforcing and Permissive values, which means any GitOps templates that hard-coded permissive: true need a rewrite. RawSelinuxProfile is now gated by an enableRawSelinuxProfiles configuration flag and a validating admission webhook, so the most privileged path through the operator is off by default. AppArmor inputs run through strict regex validation, raw policy payloads are capped at 500 KB, and the eBPF profile recorder picked up explicit resource limits. Why a cluster team should care The point of an operator like this is to take the profile out of the host's filesystem and into the API. That changes the blast radius of "we shipped a container with no profile at all." With SPO and a workload-attached profile, the r

Hi folks! I’m the architect behind WLOADCTL, a commercial workload scheduling system for enterprise automated task orchestration and RPA docking. A quick share of my daily work focus: Distributed task scheduling core development with Java & C Cross-system automation scripts built by Python & Shell Backend frontend based on SpringBoot + Vue3 Edge traffic protection & access optimization using Cloudflare Enterprise RPA integration to automate repetitive backend operations I’ve been tackling a lot of real-world pain points like cross-Linux distro compatibility, high-frequency API access security and mass task concurrency control recently. If you’re working on workload scheduling, backend automation or Cloudflare security tuning, feel free to leave a comment to chat!

An innovative Moroccan platform for finding, renting, and selling real estate, offering a simple and seamless experience tailored to the local market. Challenge Launch Sarout.ma, an innovative Moroccan platform dedicated to searching, renting and selling real estate, on an ultra-competitive market dominated by a few historical players often criticized for dated ergonomics and uneven listing quality. The challenge: build an intuitive, modern real estate marketplace able to connect individual owners, agencies and tenants across all of Morocco — Casablanca, Rabat, Marrakech, Tangier, Agadir — with clear navigation and smart search. It also required enriched, geolocated listings updated in real time, and a journey differentiated by user profile (searcher, owner, professional agency). Solution Development of a site with a clean, fully responsive interface, designed mobile-first since most real estate searches in Morocco happen on smartphones. Integration of advanced dynamic filters (city, neighborhood, price, surface, number of rooms, property type, furnished/unfurnished) with instant result refresh. Listing management via a complete owner dashboard: creation, editing, view statistics, photo management with multi-upload and automatic compression, scheduling of paid promotions. Each property page has an SEO-optimized URL, rich descriptive content, precise geolocation on an interactive map, and the option to directly request a viewing. SEO architecture focused on local ranking: category pages per city and neighborhood, Schema.org RealEstateListing markup, dynamic sitemap. Email alert system for saved searches, listing moderation, and a professional agency dashboard for premium accounts. Results A high-performing, accessible real estate portal that significantly simplifies property search for individuals and strengthens listing visibility across Morocco. The interface fluidity stands out in a market where competition remains rough around the edges. Steady growth in publishe

Lab 1 – Linux Navigation & Files (20 points) Task 1 Create the following structure. /home/student/ ├── project │ ├── logs │ ├── scripts │ └── backup Requirements create all directories create app.log error.log install.sh inside correct folders. Task 2 Move app.log into backup Task 3 Delete error.log Task 4 Find install.sh using only one command. Lab 2 – Permissions (20 points) Create secret.txt Requirements Owner read/write Group read Others no access Verify permissions. Create a new user developer Switch to that user. Can the user read secret.txt Explain why. Lab 3 – Processes (20 points) Start a process Example sleep 500 Questions Find PID Kill the process Verify it stopped. Bonus Find the top five processes using the most memory. Lab 4 – Disk Space (20 points) Create a directory practice Generate a file about 100 MB. Questions How much disk space is used? How much free disk space remains? Which command shows directory size? Lab 5 – Networking (30 points) Find Your hostname private IP default gateway DNS server Ping 8.8.8.8 Questions Did it work? Ping google.com If this fails but 8.8.8.8 works, what is the problem? Display All listening ports. What service is listening on port 22? Lab 6 – Troubleshooting (40 points) Scenario 1 A user says "Internet is not working." Show the commands you would run. Expected ideas ip addr ping 8.8.8.8 ping google.com ip route cat /etc/resolv.conf Explain each step. Scenario 2 A website is down. Questions How do you verify server is running? nginx is running? port 80 is listening? firewall issue? logs? Commands should include systemctl status nginx journalctl -u nginx ss -tuln curl localhost systemctl restart nginx Scenario 3 SSH stopped working. How would you troubleshoot? Expected ping server ssh localhost systemctl status ssh ss -tulpn journalctl -xe systemctl restart ssh Lab 7 – Mixed Practical (Best Assessment) Tell students: You are the new Junior DevOps Engineer. The manager asks you to prepare a server. Complete all tasks. Ta

A follow-up to Part 1 ( EN on LinkedIn · RU on Habr ), where we stood up a two-tier PKI: a Root CA and three intermediate CAs — Person, Server and Code. At the end of Part 1 I promised we'd learn to revoke certificates and run OCSP. That's what we'll do here. Like Part 1, this article is meant as a hands-on manual : for every command and extension we touch, there's an extended reference of the parameters you can actually use — with syntax, allowed values, defaults and gotchas. If you don't need a given option right now, just skim past the table; it's there so you don't have to dig through man later. Each section has the same shape: first the working commands for the common case, then the full parameter reference. Tested on versions. Flag names, defaults and extension syntax were verified against the official documentation of OpenSSL master , plus nginx and Apache mod_ssl. OpenSSL evolves per branch: anything marked "OpenSSL 4.0 / master" (for example the nonss qualifier on authorityKeyIdentifier ) is not yet available in the stable 3.x line. If you're on OpenSSL 3.0–3.6, double-check the disputed options with openssl <cmd> --help or your version's man before copy-pasting config. The numeric openssl verify error codes above 40 also shifted between branches — confirm them against your version's header. In this part: How a revoked certificate differs from an expired one, and why we need two mechanisms — CRL and OCSP. Adding the distribution points (CDP) and AIA to the config so issued certificates "tell" verifiers where to check them. Revoking a certificate and working with the CA database. Generating a CRL and inspecting it with openssl crl . Checking revocation with openssl verify . Running an OCSP responder: issuing its certificate, starting the daemon, querying status. Publishing the CRL and OCSP over HTTP (nginx), configuring OCSP stapling and revocation checking on the web server. All paths, file names and config sections are the same as in Part 1. Where you name

Recently, we encountered a case on a RHEL 9 machine where an RPM query did not show any information about installed package even though the package files were present in the filesystem. Although RPM reported that the package was not installed, I was still able to run tcpdumpcommand and use it without any issues. The binary was present there in the filesystem and I was able to run it successfully. Fixing RPM Database Desynchronization on RHEL - bidhankhatri.com.np Recently, we encountered a case on a RHEL 9 machine where an RPM query did not show any information about installed package even though the package files were present in the filesystem. bidhankhatri.com.np

When we started Reach , the plan was simple. We had a bunch of small businesses we were already in touch with - real SMBs, the kind that live on WhatsApp and don't have a "tech team." We'd give each of them an AI agent that talks to their customers, hand them a clean starter template for the instructions, and let them tweak it from there. That was the whole bet: give people a good starting prompt and a template, and they'll play along. We were so wrong it's almost funny now. The part nobody warns you about Here's the thing about prompt engineering that you only learn by watching non-technical people try to do it: writing the instructions is not the hard part. The hard part is thinking about the task in the abstract . We'd hand a business owner an agent that mostly worked, and say "just adjust the instructions when it gets something wrong." Sounds easy. It is not. Sitting down and imagining all the ways a conversation could go, then writing rules for a machine to follow - that's a skill. It's basically a job. And it's a completely different job from running a flower shop or a real estate office. So they got stuck. They'd open the instructions editor, stare at it, and close it. The agent stayed mediocre because the iteration loop we designed required them to be part-time prompt engineers. A few of them just quietly left. That stung, but it taught us the actual problem. What "iteration" actually looked like We started doing the iterations for them, manually. And once we did that a few dozen times, a pattern jumped out. The feedback never led to an abstract change. It was never something that made us "rethink the agent's persona" or "restructure the system prompt." It was tiny, concrete, and tied to a real conversation: "It suggests all of our services, but honestly most customers only care about these three - push those." "It pulled our opening hours from the website and they're just wrong. We changed them months ago." These were one-line corrections. The owner knew ex

Prototype vs MVP: How to Validate an Interactive Product Before Overengineering It A common early-stage product mistake is treating development output as product validation. The team creates screens, components, integrations, API endpoints, and increasingly complex application logic. The backlog is moving. The product is growing. But the core assumption may still be untested. Before building a full MVP, a startup should be able to answer a simpler question: What exactly are we trying to validate? For some products, a clickable UI prototype is enough. For others — especially products involving real-time 3D, WebAR, WebXR, data visualization, or spatial interaction — the experience cannot be validated through static screens alone. The team may need a functional interactive prototype. Prototype and MVP solve different problems A prototype is an experiment. Its purpose is to explore the concept, test the main interaction, and expose incorrect assumptions early. An MVP is a usable product. Its purpose is to deliver real value in production conditions and test market demand. A prototype helps validate: interaction logic; product comprehension; technical feasibility; the main user flow; visual communication; investor or stakeholder response. An MVP helps validate: real usage; retention; willingness to pay; production performance; operational requirements; market demand. The distinction becomes important because prototypes and MVPs require different engineering decisions. A prototype should be focused and fast. An MVP needs a more reliable technical foundation. Building the second before learning from the first can lead to unnecessary architecture, unused features, and expensive rework. Define the hypothesis before choosing the stack Teams often begin technical discussions too early. Should we use React? Should the 3D layer be built with Three.js? Do we need WebXR support? Should the backend be serverless? These may be relevant questions, but they are not the first questions