INSTALL KITS

sudo apt install wget git curl vim -y

INSTALL PATCHED FONTS

wget https://github.com/romkatv/dotfiles-public/raw/master/.local/share/fonts/NerdFonts/MesloLGS%20NF%20Regular.ttf &&

wget https://github.com/romkatv/dotfiles-public/raw/master/.local/share/fonts/NerdFonts/MesloLGS%20NF%20Bold.ttf &&

wget https://github.com/romkatv/dotfiles-public/raw/master/.local/share/fonts/NerdFonts/MesloLGS%20NF%20Italic.ttf &&

wget https://github.com/romkatv/dotfiles-public/raw/master/.local/share/fonts/NerdFonts/MesloLGS%20NF%20Bold%20Italic.ttf

double-click the font file and click Install

INSTALL ZSH

sudo apt install zsh -y

INSTALL OH MY ZSH

sh -c “$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)”

INSTALL PLUGIN

Theme PowerLevel10k

git clone https://github.com/romkatv/powerlevel10k.git $ZSH_CUSTOM/themes/powerlevel10k

Plug-in zsh-autosuggestions

git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions

Plug-in zsh-syntax-highlighting

git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting

Plug-in Zsh-z

git clone https://github.com/agkozak/zsh-z $ZSH_CUSTOM/plugins/zsh-z

CONFIGURE PLUGIN

vi ~/.zshrc

1. Modify the theme

ZSH_THEME=”powerlevel10k/powerlevel10k”

2. Add plugins to be activated (Plugins)

plugins=(git zsh-autosuggestions zsh-syntax-highlighting zsh-z)

source ~/.zshrc

After the modification is applied, because the first time Powerlevel10k is used, the setting will be automatically activated, and the setting can be completed according to the manufacturing requirements.

• Unified Interface: Access all your messaging and productivity apps in one place, eliminating constant app-switching.

• Open Source: Transparent and community-driven, with no paid subscription model.

• Resource Efficiency: Smart hibernation keeps inactive services from consuming resources.

• Workspaces: Separate personal and professional accounts for better organization.

Installation Methods by Operating System

Windows:

• Recommended: Download the .exe (AutoSetup) installer from the Ferdium website.

macOS:

• Homebrew: Run brew install --cask ferdium.

• Direct Download: Download the .dmg file from the Ferdium website.

Linux:

• Snap: sudo snap install ferdium.

• Flatpak: flatpak install flathub org.ferdium.Ferdium.

• AUR (Arch): yay -S ferdium-bin.

Navigating a Cross-Platform Reality

My daily workflow spans Windows, macOS, and Linux. This cross-platform existence has pushed me to evaluate SSH clients not just on raw functionality, but on their ability to integrate seamlessly across diverse operating systems. A truly great client must be reliable, intuitive, and consistent — no matter which machine I’m working from.

The Ongoing Search for the Ideal Tool

From minimalist command-line utilities to feature-rich graphical clients, I’ve tested them all. Some excelled in speed, others in session management, and a few offered innovative features that briefly caught my attention. But none truly felt like the “one” — until I settled on two that consistently deliver what I need.

My Choice: SecureCRT and Trilix

After years of trial and error, my favorites are SecureCRT and Trilix.

• SecureCRT stands out for its professional-grade reliability, advanced session management, and robust security features. It’s a powerhouse for administrators who demand stability and precision.

• Trilix, on the other hand, offers a modern, streamlined experience that balances usability with flexibility. It’s lightweight yet powerful, making it a joy to use across platforms.

Together, they cover the full spectrum of my SSH needs — from heavy-duty administration tasks to quick, everyday connections.

SecureCRT

• Professional-grade reliability: After 25+ years in Linux/Unix administration, stability is non-negotiable. SecureCRT is known for its rock-solid connections and enterprise-level security.

• Advanced session management: It handles dozens (or hundreds) of simultaneous sessions with ease, letting you organize, script, and automate workflows.

• Cross-platform consistency: Works smoothly across Windows, macOS, and Linux, which matches your daily multi-OS usage.

• Customization & scripting: Its support for Python and VBScript means you can tailor it to your exact workflow.

Trilix

• Lightweight and modern: Trilix offers a streamlined, fast experience without the heavy overhead of some older clients.

• Cross-platform usability: Like SecureCRT, it runs well on Windows, macOS, and Linux, making it a natural fit for your daily environment.

• User-friendly design: It balances simplicity with flexibility, so you can jump into quick connections without sacrificing advanced features.

• Complementary to SecureCRT: Where SecureCRT is heavy-duty and enterprise-focused, Trilix is nimble and efficient — perfect for everyday tasks.

Why I Use Both

After trying countless SSH clients, I’ve learned that no single tool can cover every scenario. SecureCRT gives me the depth and power needed for complex administrative work, while Trilix offers the speed and simplicity required for everyday cross-platform tasks. Together, they form a toolkit that reflects decades of experience and the flexibility to move seamlessly between Windows, macOS, and Linux.

1. Secure Access with SecureCRT

When managing 300+ hosts, secure and efficient SSH access is critical.

• Session Management: SecureCRT allows you to organize sessions by groups (e.g., production, staging, dev).

• Secure Authentication: Use key-based authentication instead of passwords to reduce risk.

• Tab Management: Multiple sessions can be opened in tabs, making it easier to switch between hosts quickly.

• Scripting Support: SecureCRT supports Python and VBScript, enabling repetitive tasks like login sequences or command execution across multiple servers.

2. Monitoring with Xymon

Xymon (formerly Hobbit) is a lightweight monitoring tool ideal for large environments.

• Health Dashboards: Provides a color-coded view of system health (green = healthy, red = problem).

• Custom Checks: You can configure checks for disk usage, CPU load, and service availability.

• Alerting: Integrates with email or SMS gateways to notify admins of issues in real time.

• Scalability: Designed to handle hundreds of hosts without heavy resource consumption.

3. Performance Tracking with Cacti

Cacti complements Xymon by focusing on performance metrics and visualization.

• SNMP Integration: Collects data from servers, switches, and routers.

• Graphing: Provides detailed graphs for CPU, memory, bandwidth, and disk I/O.

• Trend Analysis: Helps identify bottlenecks and forecast resource needs.

• Capacity Planning: Essential for environments where scaling is frequent.

4. Automation Scripts

Manual work across 300 hosts is unsustainable. Automation scripts are the backbone of efficiency.

• Backup Automation:

• Nightly backups using rsync or tar.

• Scripts can push backups to centralized storage or cloud.

• Log Rotation:

• Automate with logrotate to prevent logs from consuming disk space.

• Custom scripts can archive logs to external storage for compliance.

• Customized Health Checks:

• Scripts to check disk usage, memory leaks, zombie processes, or failed services.

• Results can be fed into Xymon or emailed directly to admins.

• Batch Execution:

• Use tools like parallel-ssh or custom scripts to run commands across all hosts simultaneously.

Putting It All Together

• SecureCRT ensures safe and organized access.

• Xymon provides real-time health monitoring.

• Cacti delivers performance insights and long-term trends.

• Automation scripts reduce repetitive tasks and enforce consistency.

• By combining these tools, sysadmins can manage hundreds of hosts daily with confidence, efficiency, and scalability.

Managing 300+ Linux hosts isn’t about brute force — it’s about smart systems. With the right mix of secure access, monitoring, and automation, sysadmins can stay ahead of problems, minimize downtime, and keep infrastructure running smoothly.

• Use Case: Seamless phone-to-desktop integration.

Resource Monitor

Resource Monitor Displays real-time system resource usage in the GNOME top bar, with metrics, CPU, RAM, swap, disk, GPU, temperature, and network activity.

• Use Case: Handy for monitoring system performance without opening a separate app.

Tailscale Status

Tailscale Status Shows and manages Tailscale VPN connections directly from GNOME Shell, simplifies secure networking management.

• Use Case: Quick access to VPN status and controls without using CLI.

Tiling Shell

Tiling Shell Adds advanced tiling window management to GNOME, with multiple monitor support, Windows 11-style Snap Assistant, custom tiling layouts, and keyboard shortcuts.

• Use Case: Great for power users who prefer tiled window management.

Workspaces Bar

Workspaces Bar Replaces the “Activities” button with workspace buttons. Simply click to switch workspaces or toggle overview. Supports custom workspace names via dconf or Workspaces Indicator.

• Note: No longer actively maintained.

• Use Case: Easier workspace navigation.

When you're managing a Linux system, it can feel like you're the captain of a pretty complicated ship. There are hundreds of commands you could use, but in my daily practice, I've found that a small handful of "heavy lifters" end up covering about 80% of what I actually need to get done

Here are five essential commands that govern routine system administration.

systemctl – The Service Manager

If there's one command I probably type more than any other, it's systemctl. It's the front door to systemd, the init system that runs on most modern Linux distributions. Think of it as the control panel for everything that runs as a service on your machine—web servers, databases, SSH, you name it.

In modern Linux distributions, systemctl is the primary tool for controlling the systemd init system. It is how you start, stop, and check the health of background services (daemons).

Common Syntax:

Checking if something is running

$ systemctl status nginx

Starting and stopping services

$ systemctl restart sshd

$ systemctl start sshd

$ systemctl stop sshd

$ systemctl reload sshd

Making sure services start automatically after a reboot

$ systemctl enable docker

Listing all running services

systemctl list-units --type=service

Great for getting a quick inventory of what’s actually running on a system, especially when I’m auditing a server I haven’t touched in a while.

What I appreciate most about systemctl is consistency. Whether I’m managing a simple service on my laptop or troubleshooting a production server, the same commands work the same way. It’s one of those tools that, once you know it, becomes second nature—like checking the dashboard before you start driving.

journalctl – The Master Log Viewer

If systemctl is the control panel, journalctl is the flight recorder. It’s the command that lets you dive into the logs collected by systemd—and trust me, once you get comfortable with it, you’ll wonder how you ever debugged anything without it.

In my early days of Linux administration, I used to bounce between log files scattered across /var/log/, trying to remember which application wrote to which file. journalctl changed all that. It pulls everything into one place, with a consistent interface that makes digging through logs actually bearable.

Here’s how I use it day to day:

Seeing everything

journalctl

Following logs in real time

journalctl -f

This is my go-to when I’m testing something or watching for errors. The -f flag follows new entries as they come in—like tail -f but for all logs. I use this constantly when restarting services or testing config changes.

Filtering by service

journalctl -u nginx

This might be my most-used journalctl command. The -u flag filters logs to a specific systemd unit. If Nginx is acting up, this shows me exactly what it’s been doing. No more grepping through /var/log/nginx/error.log and wondering if there’s more context elsewhere.

Checking logs from the last boot

journalctl -b

When a server crashes or behaves strangely after a reboot, this is invaluable. It shows logs only from the current boot. Add -b -1 to see the previous boot—perfect for investigating what went wrong before a system went down.

Finding recent logs

journalctl --since “10 minutes ago”

journalctl --since “09:00” --until “12:00”

I use time-based filtering constantly. Instead of scrolling through thousands of lines, I can pinpoint exactly when an issue happened. It’s especially useful when someone says “the site went down around 2 PM” and I need to see what happened right before that.

What I love about journalctl is that it turns log management from a scavenger hunt into a deliberate search. Instead of remembering that SSH logs go to /var/log/auth.log and cron logs live somewhere else entirely, I just point journalctl at what I care about and it gives me everything in a clean, structured format.

It’s one of those tools that seems simple on the surface but reveals new depths the more you use it. These days, when something breaks, journalctl -u [service] -b -p err is usually my second command—right after systemctl status.

top / htop – Process & Resource Monitoring

If you’ve ever logged into a server and thought “why is everything so slow?”, top is usually the first thing I reach for. It’s like looking at the dashboard of your system—showing you exactly what’s consuming CPU, memory, and which processes are fighting for attention.

top – The Old Reliable

top comes pre-installed on just about every Linux system out there. When I’m working on a fresh server or something minimal that doesn’t have extra tools, I know top will be there.

The header tells me the story:

• Load average – The three numbers show system load over 1, 5, and 15 minutes. If they’re climbing and getting close to or exceeding your CPU core count, things are getting busy.

• %CPU and %MEM – These columns instantly show me which processes are hogging resources. I sort by CPU usage by pressing Shift+P or by memory with Shift+M.

My daily top workflow:

1. Run top and immediately press Shift+M to sort by memory—helps me spot memory leaks fast

2. Press Shift+P to switch back to CPU sorting when I want to see what’s churning

3. Press c to see full command paths (helps me distinguish between multiple instances of the same process)

4. Press k and enter a PID to kill a runaway process without leaving the interface

5. Hit q to quit

It’s not pretty, but it works. And when you’re SSH’d into a server that’s barely responsive, top loads quickly and gives you what you need.

htop – The Modern Upgrade

htop is everything I liked about top, but friendlier. It’s not always installed by default—apt install htop or yum install htop is usually my second task on a new system—but once it’s there, I rarely go back to plain top.

My daily htop workflow:

1. Launch htop

2. Press F6 and select PERCENT_CPU to find the noisiest processes

3. Press F4 and type a service name to zoom in on it

4. Press F5 occasionally to see the parent-child relationships

5. Press F9 on anything that needs to go away

I keep both in my toolbox because they serve different purposes:

• top – When I’m on a minimal system, over a slow connection, or need something that’s guaranteed to be there. It’s lean and gets the job done.

• htop – For my daily work, especially on systems I manage regularly. The extra visual feedback, filtering, and ease of navigation make it worth the two seconds it takes to install.

Between top and htop, I probably spend more time looking at these than any other commands besides systemctl and journalctl. When something’s slow, when a process is misbehaving, or when I just want to see what this server is doing—this is where I start.

df & du – Storage Management

Few things ruin a day faster than a production server grinding to a halt because the disk filled up. I’ve learned this the hard way—multiple times. That’s why df and du are part of my daily routine. One gives me the big picture, the other helps me zoom in on the culprit.

They’re siblings in the Linux command family. df (disk free) tells you about your filesystems. du (disk usage) tells you about your directories. Together, they’ve saved me from more late-night emergencies than I care to admit.

df – The Big Picture

When I first log into any system, especially one I haven’t checked in a while, df is usually my first stop. It shows me how much space I have left—and more importantly, how close I am to running out.

df -h

The -h flag is essential. It gives me "human-readable" output—G for gigabytes, M for megabytes, instead of numbers that look like someone's phone number.

I scan down the Use% column. Anything over 90% gets my immediate attention. Anything at 95% or above? I stop whatever I'm doing and start investigating.

du – The Detective

If df tells me something is wrong, du tells me what is wrong. It digs into directories and shows me exactly where the space is going.

du -sh /home

-s summarizes, -h makes it readable. This tells me the total size of /home. When I have a disk filling up, I start at the root of the problem filesystem and work my way down.

A Real-World Example

Yesterday I got an alert that a server was at 92% disk usage. Here’s how I used df and du together:

df -h

Output showed /dev/sda1 at 92% usage. The mount point was /.

du -sh /var /home /opt /tmp

/var was 45GB. Everything else was small.

du -sh /var/*

/var/log was 42GB. Now we're getting somewhere.

du -sh /var/log/*

/var/log/nginx/access.log was 38GB. A rotated log that never got cleaned up.

Problem identified in under a minute. From there, I could decide whether to rotate it, archive it, or investigate why it grew so fast.

apt / dnf / pacman – Package Management

If there’s one thing every Linux administrator does daily, it’s installing, updating, or removing software. But depending on which Linux distribution you’re working with, the command looks different. I’ve spent time on Debian-based systems, Red Hat family servers, and Arch Linux machines—and each has its own package manager. Learning the quirks of each has saved me from fumbling around when I switch contexts.

Think of these as the gatekeepers. They handle dependencies, resolve conflicts, and make sure the software you want actually works with what you already have. When I first started, I’d download random .deb or .rpm files and try to install them manually. I learned pretty quickly that using the package manager is almost always the better path.

apt – The Debian/Ubuntu Standard

apt is what I use most often. It runs on Debian, Ubuntu, and all their derivatives. It’s straightforward once you get the hang of it, and it’s hard to break things if you stick to the basics.

apt update

apt upgrade

apt full-upgrade

apt install nginx

apt remove nginx

apt purge nginx

apt autoremove

apt search nginx

dnf – The Red Hat/Fedora Workhorse

dnf is the modern successor to yum. It runs on Fedora, RHEL, Rocky Linux, AlmaLinux, and others. If apt feels like a friendly librarian, dnf feels like a professional warehouse manager—organized, deliberate, and capable of handling complex tasks.

dnf update

dnf install nginx

dnf remove nginx

dnf upgrade

dnf group list

dnf group install “Web Server”

dnf search nginx

dnf info nginx

dnf search nginx

dnf info nginx

dnf history

pacman – The Arch Linux Power Tool

pacman is different. It runs on Arch Linux and its derivatives. Where apt and dnf try to be user-friendly, pacman is fast, minimal, and assumes you know what you're doing. When I first used Arch, pacman felt terse and intimidating. Now I appreciate its speed and simplicity.

pacman uses a different pattern. It’s fast—really fast. Package installs that take noticeable time in apt or dnf feel instant in pacman. And because Arch keeps packages close to upstream, I get the latest software without waiting for backports or special repositories.

Updating the system

pacman -Syu

Installing software

pacman -S nginx

Removing software

pacman -R nginx

Searching for packages

pacman -Ss nginx

Checking installed packages

pacman -Q

Cleaning the cache

pacman -Sc

I don’t have a favorite—I have muscle memory for each:

• apt – When I’m on Ubuntu or Debian servers. I think in update then upgrade. It’s predictable and forgiving.

• dnf – When I’m working with RHEL family systems. I appreciate the history feature and group installs. It feels robust and enterprise-ready.

• pacman – When I’m on Arch. I move faster, type less, and stay closer to the bleeding edge. I pay more attention to what I’m doing because there’s less hand-holding.

Between these three package managers, I can handle software management on just about any Linux system that crosses my desk. They each have their personality, but they all do the same job—keeping my systems up to date, clean, and running the software I need.