DEV Community: ServerAvatar

How to Fix Too Many Authentication Failures Error in SSH

Meghna Meghwani — Mon, 17 Aug 2026 07:23:38 +0000

Picture this: you’re in the middle of a deployment, and suddenly your SSH connection refuses to connect. The server returns a Too Many Authentication Failures error like:

Received disconnect from host: 2: Too many authentication failures for root

You have entered the correct password. You have the correct SSH key. Nothing appears to be wrong with your credentials, yet the connection keeps failing. This error can be confusing because “Too many authentication failures” doesn’t necessarily mean that you entered the wrong password too many times.

One of the most common causes is that your SSH client is offering multiple identities, often from your SSH agent, before it gets to the correct key. The server reaches its MaxAuthTries limit and closes the connection before successful authentication can occur.

In this guide, we will explain why this happens, how to diagnose the exact cause, and several ways to fix it, from the quickest command-line solution to a permanent SSH configuration. We will also cover how to prevent the problem in CI/CD environments and some additional SSH security practices.

Let’s dig in.

TL;DR

A common cause of “Too many authentication failures” is that the SSH client offers multiple identities before successful authentication.
OpenSSH’s MaxAuthTries controls how many authentication attempts are permitted per connection. Its default is commonly 6.
Having many keys loaded into ssh-agent does not automatically mean there is a problem. The important question is which identities SSH actually offers during the connection.
Quick fix: Specify the correct key and use IdentitiesOnly=yes:

ssh -o IdentitiesOnly=yes -i ~/.ssh/your_specific_key user@hostname

Recommended long-term fix: Configure IdentitiesOnly yes and IdentityFile for the host in ~/.ssh/config.
Increasing MaxAuthTries can be useful in specific environments, but it should generally be a last resort.
For automation and CI/CD, explicitly specify the intended SSH identity instead of allowing the client to try multiple keys.

         SSH Client
             │
             ├── Work Key
             ├── GitHub Key
             ├── AWS Key
             ├── Old Key
             └── Correct Server Key
                    │
                    ▼
                SSH Server
                    │
                MaxAuthTries = 6
                    │
                    ▼
        Too many authentication failures

What Does “Too Many Authentication Failures” Actually Mean?

The error message can make it sound like you’ve simply entered an incorrect password too many times. That’s not necessarily what happened.

A common scenario looks like this:

Your SSH client has multiple identities available.
Some of those identities may come from ssh-agent.
SSH offers identities to the server during authentication.
The server rejects identities that aren’t authorized for the target account.
The number of authentication attempts reaches the server’s MaxAuthTries limit.
The server terminates the connection before the correct identity is successfully used.

OpenSSH’s MaxAuthTries setting controls the maximum number of authentication attempts permitted per connection. The default is commonly 6. The exact value can be changed by the server administrator.

You can refer to the OpenSSH sshd_config documentation for the current behavior and default values.

For example, imagine your SSH agent contains several keys:

work-key
github-key
aws-key
old-project-key
personal-key
server-key

Your intended server-key may be valid for the destination server, but if SSH offers several other identities first, the server may reach its authentication-attempt limit before the correct key gets a chance to authenticate.

This is why you can have a perfectly valid SSH key and still receive:

Too many authentication failures

Important clarification: Having more than six keys in your SSH agent does not automatically mean you will get this error.

The important thing is how many authentication attempts are actually made during the connection and how your SSH client and server are configured.

That’s why checking the verbose SSH output is important before changing server-side settings.

Why this matters for your fix: Most quick fixes just tell you to specify the key with -i. That’s not wrong, but it’s incomplete. The real fix is telling SSH to stop offering other keys entirely, which is what IdentitiesOnly yes does.

How SSH Agent Can Contribute to the Problem

An SSH agent such as ssh-agent can store multiple private-key identities so you don’t have to repeatedly enter passphrases.

You can check which keys are currently loaded with:

ssh-add -l

You might see something like:

256 SHA256:xxxx work-key (ED25519)
256 SHA256:xxxx github-key (ED25519)
256 SHA256:xxxx aws-key (ED25519)
256 SHA256:xxxx old-project-key (ED25519)
256 SHA256:xxxx personal-key (ED25519)

Having multiple keys isn’t inherently bad. The problem occurs when SSH offers identities that aren’t appropriate for the target server and consumes the server’s available authentication attempts before the correct identity succeeds.

This is one reason IdentitiesOnly yes is so useful. It allows you to tell SSH to use only the identity I explicitly configured for this host.

OpenSSH documents IdentitiesOnly specifically for situations where ssh-agent offers multiple identities.

Read Full Article: https://serveravatar.com/fix-too-many-authentication-failures-ssh

How to Set Up Amazon Lightsail Server with ServerAvatar

Meghna Meghwani — Sat, 15 Aug 2026 06:30:00 +0000

If you have been poking around AWS to host a website or web application, you’ve probably heard of Amazon Lightsail. An Amazon Lightsail Server is AWS’s simplified VPS offering, the short version of EC2 that strips away the most confusing parts while still giving you the reliability of Amazon’s infrastructure.

But here’s the catch: AWS itself isn’t simple. Even with Lightsail being the “easy” entry point, connecting it to a server management panel like ServerAvatar and actually getting a working server takes a few steps. You have to set up IAM permissions, create API credentials, navigate two dashboards, and then figure out what on earth to do during the installation process.

That’s exactly what this guide is for. I have walked through this process a few times, both on Amazon Lightsail and ServerAvatar. The AWS IAM setup is the part that trips most people up. Not because it’s complicated, but because the documentation assumes you already know what IAM is and why you’re creating a separate user instead of using your root account.

Let me walk you through it step-by-step. By the end of this guide, you’ll have a fully configured Amazon Lightsail server managed through ServerAvatar, ready to host your PHP or Node.js application.

TL;DR

What is Amazon Lightsail, and Why Use It with ServerAvatar?

Amazon Lightsail is a simplified cloud hosting service from AWS that makes it easier to launch and manage virtual private servers without dealing with the complexity of a full AWS infrastructure setup. It is well suited for developers, agencies, small businesses, and teams that need a straightforward VPS environment.

Why Choose Amazon Lightsail?

Lightsail provides a simpler way to get started with AWS while still benefiting from its underlying cloud infrastructure.

Simple VPS deployment: Launch a server with minimal configuration.
Predictable pricing: Plans include compute, SSD storage, and data transfer.
Flexible resources: Choose a server size based on your workload.
AWS infrastructure: Benefit from AWS’s cloud infrastructure and ecosystem.
Multiple use cases: Suitable for WordPress, PHP applications, APIs, and websites.

Where ServerAvatar Fits In

Lightsail provides the server, but server administration can still require SSH and command-line knowledge. ServerAvatar adds a graphical management layer that simplifies everyday tasks.

With ServerAvatar, you can:

Deploy and manage multiple websites.
Install and switch between PHP versions.
Create and manage databases.
Configure SSL certificates.
Manage Nginx, Apache, and OpenLiteSpeed.
Monitor server performance.
Manage cron jobs and backups.
Handle common server tasks from a centralized dashboard.

Why Combine Amazon Lightsail with ServerAvatar?

Using both services brings together the infrastructure capabilities of AWS with a more user-friendly server management experience.

Lightsail provides the VPS and cloud infrastructure. ServerAvatar handles server and website management.

Result: less command-line work and an easier way to manage production websites and applications.

Why Create an IAM User Instead of Using the Root Account?

Using your AWS root account for API access can create unnecessary security risks. The root account has unrestricted access to your AWS environment, so its credentials should be protected and used only when absolutely necessary.

Why Use a Dedicated IAM User?

Create a separate IAM (Identity and Access Management) user for ServerAvatar and grant it only the permissions required to manage your Lightsail resources.

Limits access: Give the user only the permissions needed for Amazon Lightsail.
Protects the root account: Avoid exposing root credentials to third-party platforms or applications.
Reduces security risks: If the IAM credentials are compromised, the potential impact is more limited than exposing root credentials.
Easy to revoke: You can disable or delete the IAM user’s access without affecting your main AWS account.
Better team management: Keep ServerAvatar’s credentials separate from those used by other developers or administrators.
Improves accountability: Dedicated credentials make it easier to identify which access belongs to ServerAvatar.
Safer third-party integration: ServerAvatar can connect using dedicated credentials instead of your unrestricted AWS root account.

Use the AWS root account for account-level administration, and create a dedicated IAM user with the required Lightsail permissions for ServerAvatar.

Read Full Article: https://serveravatar.com/set-up-amazon-lightsail-server-with-serveravatar

Website Load Testing Guide: Test Performance at Scale

Meghna Meghwani — Fri, 14 Aug 2026 06:15:00 +0000

If you’ve managed web servers or applications for any length of time, you’ve probably seen this happen: a new feature or campaign goes live, traffic suddenly spikes, and Website Load Testing becomes critical when your website starts returning 503 errors at exactly the moment you need it to perform.

What happens next is usually a scramble, SSH into a server you haven’t checked in months, inspect running processes, restart services, and make infrastructure changes based on guesswork. Eventually, the traffic settles, the site recovers, and the immediate crisis is over.

But that kind of incident is often preventable. Load testing helps you find your website’s limits before your users do.

In this guide, we will cover what load testing is, why it matters at every scale, how to run your first test using loader.io (the most accessible free tool available), what your results actually mean, how to find and fix bottlenecks, and how to make load testing a normal part of how you ship software.

TL;DR

Load testing answers one critical question: how many concurrent users can your server handle before it falls over?
Without it, you’re guessing about capacity, and guessing wrong right when it matters most
loader.io is the simplest free tool to get started: no install, browser-based, generous free tier
Your three essential numbers: concurrent user target, response time threshold, and peak traffic window
Run load tests before every major deployment, not after your site goes down

What Load Testing Actually Is

Let me clear up some confusion first, because “load testing” gets thrown around interchangeably with a few related terms that mean different things.

Load testing is specifically about simulating concurrent users hitting your site and measuring how your server behaves under a expected load. You’re asking: “When 500 people are on this site at the same time, what happens?”

Stress testing pushes beyond that, you keep adding users until something breaks, then you figure out exactly where the ceiling is. Soak testing holds a sustained load over hours or days to catch memory leaks or database connection pool exhaustion that only shows up over time.

Most small teams skip all of this and call it “load testing” when they open the site in three different browsers and hit refresh a few times. That’s not load testing. That’s optimism.

This distinction is important because each testing approach is designed to answer a specific performance question:

Load test: “Can the website reliably handle its expected peak traffic?”
Stress test: “At what point does this fall over, and what breaks first?”
Soak test: “Can the system maintain stable performance during prolonged, normal traffic without gradual degradation?”

A complete performance testing strategy should consider load, stress, and soak testing. For this guide, we’ll focus on load and stress testing since those are where most teams see the biggest gap in understanding.

Why Most Teams Skip It

I get it. Load testing feels like a luxury. You have a small server, modest traffic, and a product that’s still finding its feet. Why simulate load when you barely have any real load to speak of?

Here’s the uncomfortable truth: load testing is most valuable precisely when you can’t afford for things to go wrong. A startup that goes down during a product launch doesn’t get a second impression. A growing SaaS that crashes right when a customer is about to upgrade has just handed that customer a reason to reconsider.

The teams that skip load testing aren’t avoiding work, they’re accumulating risk. VPS that handles your blog fine today might handle 10x traffic fine too, or it might fall over at 3x. You genuinely don’t know until you test.

What load testing gives you that nothing else can:

A real number for capacity. Not a guess. Not a “probably fine.” An actual number of concurrent users your setup can handle before performance degrades past an acceptable threshold.
The location of your bottleneck. Is it the database? The application code? The web server config? The network? A load test with proper instrumentation tells you where things back up.
A baseline before you change anything. If you optimize your database queries and then run a load test, you have before-and-after data.
Confidence to scale. When you know your current ceiling, you know exactly when to provision more resources, and you can do it before an incident, not during one.

Setting Your Performance Targets: The Three Numbers That Matter

Before you run any test, you need to define what “passing” looks like. This is where a lot of teams get stuck, they run a load test and get a wall of graphs and don’t know what any of it means.

Here’s what you’re actually looking for:

1. Your concurrent user target

This is the number of simultaneous active users your site needs to handle at peak. Not total daily visitors, active users. Someone who has the page open and is interacting with it.

A practical way to estimate this: take your peak hour’s pageviews, divide by 60 to get per-minute, then multiply by your average session duration in minutes. If you get 6,000 pageviews in your busiest hour and sessions average 3 minutes, that’s roughly 300 concurrent users at peak.

If you don’t have analytics that can give you this, err on the side of 2x what you’ve seen. You can always calibrate after your first real test.

2. Your response time threshold

What response time is acceptable for your application? Define it in milliseconds and be specific.

For a static blog, 3 seconds might be perfectly fine. For a SaaS dashboard where users are actively working, anything over 1 second feels sluggish. For an e-commerce checkout flow, 2 seconds is a reasonable ceiling. For an API, you might need sub-200ms.

Write this number down before you test. It becomes your pass/fail criterion. Without it, any result can be interpreted as either a pass or a failure depending on your mood that day.

3. Your peak traffic windows

Map when your traffic actually spikes. Email campaigns, social posts, scheduled jobs, and API batch processes create load patterns. A test that runs at 3 AM when traffic is low tells you nothing about your morning peak.

Once you know these three things, your concurrent user target, your response time threshold, and your peak windows, you have a test brief. Everything else is execution.

Why loader.io Is the Best Starting Point

There are a dozen load testing tools. k6, Apache Benchmark, Locust, JMeter, Gatling, Blitz, each has strengths. For teams getting started, loader.io is the right choice for one reason: friction.

It runs in a browser. There’s nothing to install. You don’t need a separate machine, a command-line interface, or a paid subscription to get meaningful results.

That’s the free tier has limits: enough to establish your baseline, not enough for daily regression testing in production. For that, you would eventually have to move to another tool or paid plan. But as a starting point, loader.io removes every excuse to not test.

Now that we understand what load testing is and why it matters, let’s put it into practice. In the following steps, we’ll use loader.io to create a test, configure realistic traffic, run the test, and analyze the results to understand how your website performs under load.

Read Full Article: https://serveravatar.com/website-load-testing

How to Create Website Backups with ServerAvatar for Disaster Recovery

Meghna Meghwani — Thu, 13 Aug 2026 06:00:00 +0000

You have heard that Website Backup is important multiple times. And yet, talking to developers and sysadmins even years into their careers, the story is almost always the same: backups were set up once, never tested, and when something broke, the restore either didn’t work or nobody knew how to trigger it in the first place.

A server update goes wrong. A misconfigured cron job overwrites a database. A client accidentally deletes their WordPress plugin folder. In every one of these cases, the difference between a five-minute restore and a full-day rebuild is whether you actually have a working backup strategy in place.

This guide is about ServerAvatar's backup system, but more importantly, it’s about thinking through your disaster recovery approach before you are staring at a broken site at two in the morning.

We will cover the three backup types ServerAvatar offers, how to actually use them in practice, what restore looks like, and the operational habits that make backups reliable rather than just theoretically existent. If you’re running applications on ServerAvatar and haven’t touched the backup system yet, this is the guide that will get you set up properly.

TL;DR

ServerAvatar offers three distinct backup types: File System, Application, and Database
Instant Backups are for right-now; Scheduled Backups handle recurring protection automatically
Archive Backups let you recover backups from applications you have deleted
Cross-server restore is available, you can pull a backup from one server and spin it up on another
Cloud storage integration (Google Drive, Amazon S3, S3 Compatible Storage, Wasabi) keeps your backups off-server
Retention policies determine how long backups live, set these consciously, not at the default
Test your restores. A backup you haven’t verified is a liability, not an asset

Why Website Backups Should Be Part of Your Disaster Recovery Plan

A backup is simply a copy of your data. Disaster recovery is the larger process of using that copy to recover your website after an incident. That distinction matters.

Imagine a WordPress application loses its database after an unexpected server problem. Having a backup from three months ago technically means the site has a backup, but it may not be sufficient to recover recent orders and customer information.

Similarly, having hundreds of backup files doesn’t help much if:

The newest backup is incomplete.
The database wasn’t included.
Backup copies stored on the same server hosting the website.
Nobody knows which backup should be restored.
The restoration process has never been tested.
Backup retention is too short.
The backup exists but cannot be accessed during an outage.

A useful disaster recovery strategy therefore needs to answer three questions:

What needs to be backed up?
How often should it be backed up?
How quickly can the website be restored?

These questions form the foundation of a reliable backup plan.

Understanding Backup Types in ServerAvatar

Before you create your first backup, it helps to understand what you’re actually backing up. ServerAvatar separates backups into three types, and choosing the right one depends on your recovery goal.

File System Backup

This captures only the files belonging to your application, your code, uploads, configuration files, everything sitting in the application directory. No database is included.

You’d reach for this when you know your application database is safe but something happened to the files themselves, maybe a deployment went sideways and overwrote the wrong directory, or a malicious script got dropped into your uploads folder.

Application Backup

This is the comprehensive option. It backs up your application files and the associated database together as a unit. If you want one backup that represents the complete state of your site at a given moment, this is the choice.

For most WordPress, Laravel, or Node.js sites in production, Application backup is what you default to.

Database Backup

Some workloads change files frequently but keep databases relatively stable. Others modify the database constantly but rarely touch files. Database-only backup lets you capture just the database on its own schedule, separate from how often you snapshot the file system.

You might run database backups hourly while file system backups run daily. That’s a valid and sensible approach.

Choosing the Right Backup Type

The best backup type depends on what you need to recover:

Need to restore application files? Use a File System Backup.
Need files and database together? Use an Application Backup.
Need to protect frequently changing database data? Use a Database Backup.
Need different backup schedules for files and databases? Use separate File System and Database Backups.

Understanding Backup File Formats

Server backups can contain different types of data, so the format used for the backup also matters. Common formats include:

.tar – Creates an archive containing multiple files without compression.
.tar.gz – Creates a compressed archive, reducing the amount of storage required for application files.
.sql – Stores a database dump as plain SQL statements.
.sql.gz – Stores a compressed SQL database dump, making it smaller and easier to transfer.

For most website backup scenarios:

Use .tar.gz for application or file backups.
Use .sql.gz for database backups.

Why Compression Matters

Compression can make a noticeable difference when you are storing or transferring backups. Compressed backups can:

Require less disk space
Reduce storage costs
Take less time to transfer
Make remote backup storage more efficient
Reduce the amount of data that needs to move between your server and backup destination

Combining the right backup type, schedule, and file format helps create a reliable disaster recovery plan, rather than simply storing backups without a clear recovery strategy.

Read Full Article: https://serveravatar.com/website-backup

How to Check Installed Laravel Version

Meghna Meghwani — Wed, 12 Aug 2026 08:00:00 +0000

Picture this: you’re debugging a production issue, a dependency broke your deployment, and you need to check installed Laravel version because you can’t remember whether your project is running Laravel 9 or Laravel 10. It happens more often than you’d think.

Knowing how to check your installed Laravel version via the command line isn’t just a trivia question, it directly affects how you troubleshoot, upgrade, and maintain your applications. The wrong version assumption can lead you to incompatible package versions, mismatched documentation, and hours of wasted debugging.

This guide walks you through every reliable way to pull your Laravel version from the terminal. I’ll cover the quickest one-liners, methods that work when you only have file access, and the ones you’d use when you need the full picture. By the end, you’ll know exactly which command fits which situation.

One thing to note upfront: Laravel follows semantic versioning. That means 8.0, 9.0, 10.0 are major releases. Patch versions (like 10.5.1) contain bug fixes. Minor versions (like 10.6) add features. Knowing this helps you interpret what you’re seeing when you run these commands.

TL;DR

Run php artisan --version from your project root, the fastest method
Open composer.json and look under require["laravel/framework"] for the locked version
Use composer show laravel/framework for detailed version info across all packages
Call app()->version() inside Laravel Tinker for the application-level version
Create a temporary web route returning app()->version() only when CLI isn’t accessible
Never leave the debug route active, remove it immediately after checking

Why Knowing Your Laravel Version Matters More Than You Think

Before we get into the commands, let’s talk about why this matters in practice. I’ve seen developers lose half a day chasing a bug that only existed because they were reading Laravel 11 documentation while running a Laravel 9 application. The version mismatch made every recommendation irrelevant.

Here’s where version awareness pays off:

Package compatibility. Some Composer packages declare version constraints like "laravel/framework": "^9.0". If you’re running Laravel 8, those packages simply won’t install. Checking your version before adding a new dependency saves you from cryptic Composer errors that don’t immediately point to the real problem.

Upgrade planning. If you’re moving from Laravel 9 to Laravel 10, you need to know your starting point. Every major upgrade has a dedicated upgrade path, and skipping versions (going from 8 straight to 10, for example) is a recipe for broken applications.

Server environment issues. When your local machine runs a different PHP version than your server, Laravel automatically uses different code paths. Knowing your Laravel version helps you understand why something works locally but fails on production.

Security. Laravel releases security patches for actively supported versions. If you’re using an older Laravel release that has reached end-of-life, you may no longer receive important security updates. You can check Laravel’s official release notes and support policy to see the current support status for each version. Version awareness is the first step toward keeping your application secure.

Method 1: The Quickest Way – php artisan --version

If you need the answer right now and you have terminal access, this is the command you want.

Open your terminal, navigate to the root directory of your Laravel project, and execute the following command:

php artisan --version

What you’ll get back is something like Laravel Framework 10.48.0. The first number 10 is the major version. The rest tells you the minor and patch release.

This works because Laravel registers an Artisan command internally that reads the framework version directly from the installed vendor files. No guessing, no file hunting. You can explore more Laravel command-line features in the official Laravel Artisan documentation.

One thing worth mentioning: this command uses your system’s PHP. If you have multiple PHP versions installed (say, PHP 8.1 and 8.3), make sure you’re running the version that matches your server’s PHP. Use php -v first if you’re unsure.

Also, php artisan won’t run if you’re inside a directory that isn’t a Laravel project. If you get an error about Artisan not being found, double-check that you’re in the right directory. Running ls and confirming you see artisan, composer.json, and a vendor/ folder is a quick sanity check.

Read Full Article: https://serveravatar.com/check-installed-laravel-version

How to Change or Reset MySQL Root Password on Ubuntu Linux

Meghna Meghwani — Tue, 11 Aug 2026 07:56:41 +0000

You’re SSH’d into your Ubuntu server. You run mysql -u root -p, type your password, and hit Enter. The response: Access denied. You try again. Same result. You check your notes, your password manager, that config file you saved somewhere, nothing works. Now you’re locked out of your own database and need to recover your MySQL Root Password.

Sound familiar? You’re not alone. Forgetting the MySQL root password is one of those things that happens to almost every developer or sysadmin at some point. The database is running, the data is there, but you cannot get in.

The good news: resetting it is straightforward, even if it feels intimidating the first time. You don’t need to reinstall anything. You don’t need to lose data. What you need is about 10 minutes, a handful of commands, and a clear sequence of steps.

This guide walks you through every scenario, changing a password you know, resetting one you’ve forgotten, handling the --skip-grant-tables method properly, and updating your applications afterward so nothing breaks. I’ve tested these steps on Ubuntu 22.04 and Ubuntu 24.04, and the process is similar on both versions.

TL;DR

You can reset a forgotten MySQL root password by starting MySQL with --skip-grant-tables, then running SQL password commands
You can change an existing password with a single ALTER USER statement while normally logged in
Always stop websites/applications pointing to the database before resetting, they will lose connection during the process
After resetting, update any application config files that store the old MySQL password
For a server management experience that takes care of these automatically, explore ServerAvatar
If your server is managed through ServerAvatar, you can update the database root password directly from the panel.

Understanding MySQL Root Access on Ubuntu

Before changing anything, it’s important to know what the MySQL root account actually is and how it differs from the Linux root user.

Before proceeding, make sure your server is actually running MySQL rather than MariaDB. Although the two database systems are closely related, there are important differences in features, compatibility, and administration. See our MariaDB vs MySQL comparison for a detailed breakdown.

MySQL root vs. Linux root: The MySQL root account is a database administrator account, separate from the Linux system root user.

MySQL root is a separate database-level administrator with full control over all databases, users, and permissions on your MySQL instance.

MySQL Authentication on Ubuntu

Ubuntu uses a plugin-based authentication system for MySQL. The authentication method configured for the root account determines how you can log in and reset its password. Common authentication methods include:

auth_socket
- Links MySQL authentication to your Linux system user.
- You can log in as MySQL root only when you’re already the Linux root user.
mysql_native_password
- Uses a stored password hash for authentication.
- A password is required to access the MySQL root account.
caching_sha2_password
- Also relies on a stored password hash.
- Authentication requires the MySQL root password.

MySQL supports multiple authentication plugins, which determine how credentials are verified when a user connects.

Check the Current Authentication Method

To find out which authentication method your MySQL root account is currently using, run:

SELECT user, host, plugin FROM mysql.user WHERE user = 'root';

The result will show the authentication plugin configured for the root user:

auth_socket – You need sudo to log in as MySQL root from Linux.
caching_sha2_password – You need the MySQL root password.
mysql_native_password – You need the MySQL root password.

Knowing the authentication method is important because it determines how you access MySQL and how you reset the root password.

MySQL Authentication Methods Compared

Read Full Article: https://serveravatar.com/change-reset-mysql-root-password

Best Facebook Groups for SysAdmins and Developers

Meghna Meghwani — Sat, 08 Aug 2026 05:20:59 +0000

Here’s what no one tells you when you first start running servers or building production software: the toughest problems rarely come with documentation. You run into a networking rule that nobody warns you about, your database starts behaving strangely at 2 AM, or a deployment script that worked perfectly for six months suddenly breaks down, and the official documentation simply… doesn’t have a solution for it. That’s where Facebook Groups for SysAdmins and Developers can help.

That’s when you need people who have been there. Not a search engine. Not a Stack Overflow thread from 2014. Actual humans who remember the time they made the same mistake you just made, and know exactly how to fix it without making you feel stupid for asking.

Facebook groups are one of the best places to find those humans. They’re informal, fast, and packed with practitioners, not spectators. The trick is knowing which ones are worth your time, and which ones are just echo chambers full of self-promotion and recycled content.

This isn’t another generic roundup. I have spent time in these communities. Some I have lurked in for months before posting. Some I have gotten real answers from. A few I have actively avoided. What follows is the breakdown of the groups that actually deliver value if you are a system administrator or developer trying to level up, written from actual experience, not a listicle rewritten from a competitor’s listicle.

TL;DR

Facebook groups can still be useful in 2026 when you find communities with genuine technical discussions.
The right group depends on your area of interest, from Linux and DevOps to software development and cloud technologies.
Active moderation and knowledgeable members generally matter more than raw member counts.
Smaller, specialized communities can sometimes provide more useful conversations than huge general-purpose groups.
Before posting a question, search the group’s previous discussions. Someone may have already solved the same problem.

Why SysAdmins and Developers Still Need Facebook Groups in 2026

With thriving communities on Reddit, Discord, Slack, GitHub Discussions, and Stack Overflow, it’s easy to assume Facebook Groups have become outdated. However, for system administrators, DevOps engineers, cloud architects, and software developers, many Facebook Groups continue to provide value that other platforms don’t always offer.

Rather than competing with modern communities, Facebook Groups complement them by bringing together experienced professionals, long-form discussions, and practical advice based on real production environments.

Why They Still Matter

1. Experienced Professionals Lead the Conversations

One of the biggest advantages of established Facebook Groups is the quality of their members. Unlike many public forums that attract a large number of beginners, these communities often consist of professionals responsible for managing production infrastructure and business-critical applications. You’ll regularly find discussions involving:

Senior System Administrators
DevOps Engineers
Cloud Architects
Infrastructure Engineers
IT Consultants
MSP (Managed Service Provider) owners
Cybersecurity specialists
Software developers building production applications

This creates an environment where technical discussions are based on practical experience rather than theory.

2. Higher Quality Answers for Real Production Problems

When you’re troubleshooting a server outage or deployment issue, generic documentation isn’t always enough. Active Facebook Groups frequently provide responses from professionals who have already encountered similar challenges in production. Instead of receiving only documentation links, members often share:

Step-by-step troubleshooting methods
PowerShell and Bash scripts
Infrastructure recommendations
Performance optimization techniques
Deployment best practices
Security improvements
Lessons learned from previous incidents

The result is a much higher signal-to-noise ratio than many open communities.

3. Practical Knowledge Beyond Official Documentation

Vendor documentation explains how products are designed to work. Community discussions explain what happens when things don’t go as planned. Members commonly discuss real-world issues involving:

Windows Server administration
Linux server management
Active Directory replication
Microsoft 365 migrations
VMware and Hyper-V virtualization
Kubernetes and Docker deployments
AWS, Azure, and Google Cloud
Backup and disaster recovery
Server monitoring and automation

These conversations often include practical workarounds, implementation tips, and deployment experiences that official documentation may not cover.

4. Better Visibility in Google Search

Another reason Facebook Groups remain valuable is their strong search presence. Searching Google for a specific error message or configuration problem frequently leads to Facebook discussions where experienced professionals have already documented the issue and shared possible solutions. These discussions often include:

Complete error messages
Log excerpts
Configuration examples
Multiple troubleshooting approaches
Community feedback on successful fixes
Updates from the original poster after resolving the issue

This makes Facebook Groups a useful knowledge base for solving uncommon or difficult technical problems.

5. Communities That Have Proven Their Value

Not every Facebook Group is worth joining, but the communities that remain active in 2026 have generally earned their reputation over many years. Most low-quality groups filled with spam and inactive members have gradually disappeared, leaving behind communities that continue to deliver meaningful technical discussions. Well-managed groups typically offer:

Active moderation
Minimal spam and promotional content
Helpful and knowledgeable contributors
Consistent technical discussions
Strong community engagement
Experienced IT professionals willing to help

For working system administrators and developers, these communities continue to be reliable places for learning, troubleshooting, networking, and staying current with evolving technologies.

Facebook Groups may no longer be the newest destination for technical discussions, but they remain one of the few platforms where experienced practitioners openly share production knowledge, review architectural decisions, and help peers solve complex infrastructure challenges.

How I Evaluated These Groups

Before diving in, here’s the criteria I used, so you know this isn’t just a random list pulled from Google:

Active moderation: No spam, no self-promotional spam threads, no low-effort content flooding the feed
Real engagement: Questions get answers, not just reactions
On-topic focus: Communities that stay relevant to sysadmins and developers, not everything-and-the-kitchen-sink groups
Practitioner presence: The membership should skew toward people who actually do the work, not managers, not onlookers
Accessibility: Groups a working professional can join and get value from without wading through 10 years of off-topic posts

These standards ruled out some popular-sounding groups that are technically “large” but practically dead or unmoderated. Size means nothing if nobody’s actually talking.

Read Full Article: https://serveravatar.com/facebook-groups-sysadmins-developers

Pipes vs xargs in Linux: Which Should You Use in Bash Scripts?

Meghna Meghwani — Fri, 07 Aug 2026 06:33:24 +0000

Picture this: you’re looking at a directory with 40 log files, and you need to delete every one that contains the word “backup.” What do you do, type each filename by hand? Copy and paste 40 times? That’s where Pipes vs xargs comes in.

That was me in my first year managing servers. I’d sit there manually typing out filenames, making typos, second-guessing myself. It was inefficient and, frankly, embarrassing. A senior admin walked past my desk one day, watched me do this for about 30 seconds, and said: “Just use xargs.” That was it. No elaboration. And honestly? That one line changed how I work with the terminal forever.

The Linux terminal is built around connecting commands, where the output of one command becomes the input for the next. However, there’s one important detail: not every command accepts data in the same way. Understanding this difference is what separates clumsy workarounds from clean, efficient one-liners.

In this guide, I’m going to break down pipes and xargs from the ground up. We’ll look at what makes them different, when each one shines, and a few xargs tricks that have saved me more times than I can count.

TL;DR

Pipes stream data as stdin between commands; xargs converts data into command-line arguments
Use pipes when chaining filters, text processors, or any command that reads stdin
Use xargs when the target command only accepts arguments (not stdin), or when you need batching, placeholders, or confirmation prompts
Filenames with spaces or special characters? Use find -print0 + xargs -0
Start with a pipe; upgrade to xargs when the pipe doesn’t work or you need more control

What Pipes (|) Actually Do

Pipes are one of the core features of Unix and Linux that make command-line workflows powerful and efficient. The pipe operator (|) connects the standard output (stdout) of one command directly to the standard input (stdin) of another command. Instead of saving output to a file first, data flows instantly from one command to the next.

You can think of a pipe as a conveyor belt in a factory. Each command performs a specific task and then passes the result to the next command in the chain. This modular approach follows the Unix philosophy of “do one thing, and do it well.”

How Pipes Work

The first command generates output.
The pipe transfers that output directly to the next command.
The receiving command processes the incoming data immediately.
No temporary files are created unless you explicitly save the output.
Data is streamed continuously, making pipelines both fast and memory-efficient.

Basic Syntax

command1 | command2

Here:

command1 produces the output.
| transfers the output.
command2 reads that output as its input.

Simple Example

ls | wc -l

ls lists all files and directories in the current location.
The output is sent through the pipe.
wc -l counts the number of lines it receives.
The final output is the total number of files and directories listed.

Instead of manually counting files, the pipe automates the entire process.

Chaining Multiple Commands

One of the biggest strengths of pipes is that you can connect multiple commands together.

find . -name "*.log" | grep -v "access" | sort | uniq

This pipeline performs several operations in sequence:

find searches for all .log files.
grep -v "access" excludes filenames containing the word access.
sort arranges the remaining filenames alphabetically.
uniq removes duplicate entries from the sorted list.

Each command focuses on a single task, making the pipeline easier to understand, maintain, and modify.

Why Pipes Are So Powerful

Pipes are widely used because they allow you to:

Combine simple commands into powerful workflows.
Process large amounts of data without creating temporary files.
Reduce disk I/O by streaming data directly between commands.
Build readable command sequences where each command has a clear purpose.
Reuse standard Linux utilities instead of writing custom scripts.

Understanding Streaming Data

The most important concept behind pipes is streaming. Rather than waiting for the first command to finish completely, many commands begin processing data as soon as it starts arriving.

This streaming behaviour offers several benefits:

Faster execution for large datasets.
Lower memory usage.
Real-time processing of command output.
Efficient handling of logs and continuously generated data.

A Common Limitation

Although pipes are incredibly versatile, not every Linux command is designed to read data from standard input (stdin).

Some commands expect:

A filename as an argument.
Direct interaction with the terminal.
Input from specific sources instead of a data stream.

When such commands are placed in a pipeline, they may ignore the incoming data or produce unexpected results. This is why a pipeline that appears perfectly valid can sometimes return no output at all.

Understanding which commands support streaming input and which require explicit file arguments is essential for building reliable Linux command pipelines.

Read Full Article: https://serveravatar.com/pipes-vs-xargs

Best Chrome Privacy Extensions to Protect Your Data in 2026

Meghna Meghwani — Thu, 06 Aug 2026 06:24:51 +0000

Open Chrome. Now, open a new Incognito window. Feel private? You’re not. Chrome Privacy Extensions can help protect your browsing activity, but Google may still see your IP address, device fingerprint, and everything synced to your account. Incognito mode only prevents local cookies from being saved; it doesn’t make you invisible.

That’s the misconception a lot of people are still running on in 2026. They have been told Incognito is “private browsing”, and they believe it. Meanwhile, advertisers, data brokers, and whoever else is paying attention have a surprisingly detailed picture of their browsing habits.beh

The best solution is not to switch browser modes but to use trusted extensions that address Chrome’s privacy gaps. Since the Manifest V3 transition changed how many extensions work, some older privacy tools may now offer limited protection. If you installed an extension a few years ago, review its current features and update status.

This guide cuts through the noise. I have tested the extensions that actually hold up in 2026’s browser environment, understand which categories matter most for different threat models, and can tell you exactly what to install and why.

TL;DR

Incognito mode helps prevent browsing activity from being saved locally after the session ends, but it does not hide your IP address or make you anonymous online.
The Chrome MV3 migration killed many old extensions; several popular picks from 2022-2024 are now dead or broken
Five tool categories matter most in 2026: content blocking, tracker learning, VPN, password management, and email privacy
You don’t need ten extensions. Most people need five carefully chosen ones
uBlock Origin, Privacy Badger, NordVPN, Bitwarden, and PixelShield make a tight, effective stack

Why Chrome Privacy in 2026 Is a Different Problem

Chrome has improved its built-in privacy tools with features like Tracking Protection, HTTPS-only mode, and Privacy Sandbox. However, these controls may not provide complete protection, especially as Google’s advertising ecosystem relies heavily on user data.

Modern tracking has also become more advanced. Techniques such as browser fingerprinting, email pixels, and cross-site identity tracking may continue monitoring users even when third-party cookies are disabled.

For stronger privacy, Chrome users should consider reliable extensions that address these gaps and remain compatible with the Manifest V3 extension model.

What this means practically: you need extensions that cover the gaps Chrome leaves, and you need to know which extensions are actually still alive and working in 2026’s MV3 extension model.

Understanding What Privacy Extensions Actually Do

Before picking tools, it helps to understand the actual threat categories. Privacy is not one problem, it’s several distinct ones that need different solutions.

Cross-site tracking is the most familiar. Third-party scripts on sites you visit collect data about your behaviour, build profiles, and sell or share those profiles with other parties. This is what ad blockers target, and what tracking protection in browsers partially addresses.

IP and traffic exposure is what your ISP, public Wi-Fi operators, and network-level observers can see when you’re not using encryption. This is what VPNs solve. Incognito doesn’t touch this at all.

Email surveillance is the one most people forget. Marketing emails, newsletters, and even internal corporate emails routinely embed invisible tracking pixels that report back when you opened the message, how long you spent on it, and often your approximate location. This requires a dedicated email tracker blocker.

Credential compromise from password reuse remains one of the most common attack vectors. If you use the same password across five sites and one of them gets breached, all five accounts are exposed. Chrome’s built-in autofill doesn’t help here, it just saves your passwords in Google’s ecosystem.

URL tracking parameters, the utm_source, fbclid, gclid strings appended to links, follow you around the web and let trackers link your sessions across sites. These can be stripped without breaking page functionality.

Read Full Article: https://serveravatar.com/chrome-privacy-extensions

CI vs CD: Understanding Continuous Integration and Continuous Deployment

Meghna Meghwani — Tue, 04 Aug 2026 09:41:20 +0000

There’s a moment every developer eventually runs into: you’ve been working on a feature for a few days, the code makes sense on your machine, you push it to production, and something breaks. CI vs CD becomes especially important when changes from other team members create conflicts that remain unnoticed until deployment, even when your code works locally.

Continuous Integration helps teams integrate changes frequently, run automated checks, and detect issues before they reach production. The terms get conflated constantly. People say “CI/CD” like it’s a single thing, but CI and CD are two distinct practices solving two distinct problems. Let’s break it all down.

In simple terms: Continuous Integration (CI) automatically builds and tests code changes. Continuous delivery keeps validated code ready for release but requires approval before production. Continuous deployment automatically releases eligible changes to production.

TL;DR

Continuous Integration (CI) helps developers frequently integrate code changes into a shared repository while automatically building, testing, and validating those changes.
Continuous Deployment automatically releases validated code to production once it meets the required deployment conditions.
Continuous Delivery sits between CI and continuous deployment. Code is automatically built, tested, and kept ready for release, but a person approves or triggers the production deployment.
CI improves code quality and developer collaboration, while continuous delivery and continuous deployment make software releases faster and more consistent.
Start with CI. Add continuous delivery or continuous deployment when your testing, monitoring, and rollback processes are reliable.
Tools such as GitHub Actions, GitLab CI/CD, Jenkins, and CircleCI can help automate these workflows.

What Actually Happens When You Don’t Use CI or CD

Before we talk about what these practices are, it helps to understand what life looks like without them, because most small teams and solo developers are living it right now.

Here’s the typical scenario: Without CI/CD, developers often test code locally and manually transfer it to the server using FTP, SFTP, or shared repositories. These manual workflows can be slow, inconsistent, and more prone to errors.

The problems stack up fast:

Bugs slip through because there’s no automated check between “I wrote this” and “it runs in production”
Deployments may be slower or more error-prone because the release process depends on manual steps and can vary between team members.
Rollbacks can be slower or more difficult when there is no documented and automated recovery process.
Bottlenecks form around whoever “owns” the deployment process.
Fear builds up around releases. The longer you go between deployments, the more changes pile up, and the bigger the risk surface when you finally push.

Sound familiar? Most teams operate in this mode for way too long because it “works fine” until it doesn’t. The real cost isn’t the occasional outage, it’s the slow drip of developer energy spent on anxiety and manual busywork instead of building.

That’s where CI and CD come in.

Continuous Integration

Continuous Integration (CI) is the practice of frequently integrating code changes into a shared repository and automatically building, testing, and validating those changes. Its goal is to identify integration issues early and keep the shared codebase stable.

When a developer pushes a commit, a CI pipeline kicks in. The code gets pulled, built, and run through a suite of tests, everything from unit tests to integration tests to linting. If something fails, the team gets an immediate alert. If it passes, the code is cleared to move forward.

Why Frequent Merges Matter

Keeping code in a branch for too long can make integration more difficult as the main codebase continues to change. Frequent merges help teams:

Reduce the risk of large and complex merge conflicts
Identify integration issues earlier
Keep code changes smaller and easier to review
Resolve problems before they become harder to fix
Maintain better alignment with the main codebase

CI supports frequent integration by automatically running checks when configured events, such as pushes, pull requests, or merges occur. This gives developers faster feedback and helps catch issues early.

Read Full Article: https://serveravatar.com/ci-vs-cd

What Are Linux Logs? Understanding Log Files and Their Uses

Meghna Meghwani — Mon, 03 Aug 2026 06:19:52 +0000

Your server is busy. Every second, processes are starting and stopping, users are logging in, databases are fielding queries, and HTTP requests are hitting your web server. Most of this happens without you noticing, until something goes wrong.

And something always goes wrong eventually. Maybe your site returns a blank white screen. Maybe SSH refuses your password even though you’re sure it’s correct. Maybe your database connection keeps timing out. When that moment hits, the first question any experienced admin asks is: what do the logs say?

That’s what this post is about. Not just what Linux logs are, but how to read them and use them. We will cover the types of logs captured, how to read log entries, and how ServerAvatar makes the whole process much easier because most of us don’t want to live inside a terminal.

If you are just getting started with server management, this is one of those skills that separates people who spend hours Googling error messages from people who open a log file and know exactly where to look.

TL;DR

Linux logs are plain-text files that record everything happening on your server, from a user logging in to a package update failing
They are your primary source of truth when something breaks, and the fastest path to figuring out what went wrong
Logs live mostly in /var/log/, but you don’t have to dig through the terminal every time, ServerAvatar lets you fetch, filter, and read them from a dashboard
This guide covers what logs actually are, why they matter more than most beginners realize, the different types you’ll encounter, and how to read them efficiently

What Exactly Is a Linux Log?

A Linux log is a record of events and activities that occur within a Linux system. These logs are created by the Linux kernel, system services, applications, and other processes running on the server.

Logs help you understand what happened on your system instead of relying on guesswork. They can provide details about:

User login and logout activity
Successful and failed connection attempts
Application errors and warnings
Service startup, shutdown, and failure events
System and kernel messages
Unexpected shutdowns or system issues
Security-related activity

Most Linux log files are stored in the following directory:

/var/log/

Many logs are plain-text files that you can view using commands such as cat, less, or tail. Some logs use a binary format and require specific tools to read.

Linux logs are essential for troubleshooting issues, monitoring system activity, and identifying potential security problems.

For a detailed guide to server management, you may also find our guide on What Is Server Management? Key Practices and Benefits helpful.

Why Logs Matter More Than Most People Think

Linux logs are useful for more than major system failures. They can help you understand everyday server activity and identify issues before they become more serious.

For example, logs can help you:

Check whether a cron job ran successfully
Verify if a user attempted to access a service
Investigate slow server performance
Identify processes that may be using excessive resources
Find errors related to applications or system services

Instead of guessing what caused an issue, logs provide records that help you understand what happened on your server. Although log files may initially look confusing, learning how to read and filter them makes troubleshooting much easier.

It is also important to ensure that the services you rely on are generating logs. Most Linux services enable logging by default, but some may limit or disable logging to reduce disk usage or improve performance. For production servers, verify that important services are recording the information you may need for monitoring and troubleshooting.

Read Full Article: https://serveravatar.com/linux-logs

How to List Users and Groups in Ubuntu Using Command Line

Meghna Meghwani — Fri, 31 Jul 2026 08:24:21 +0000

If you’ve been working with Ubuntu for any length of time, you’ve likely encountered situations where you need to list users and groups in Ubuntu, check which user accounts exist on the system, or find out which groups a specific user belongs to.

Maybe you’re onboarding a new team member and need to grant them access to a specific directory. Maybe you’re debugging a permission error and can’t understand why a user can’t reach a file they should have access to. Or maybe you’re inheriting a server from someone else and need to audit who’s on it.

That’s exactly what we’re covering today. This guide walks you through everything you need to know about listing users and groups in Ubuntu using the command line. We’ll look at the files that store this information, the commands that query them, and some practical scenarios where this knowledge actually matters.

TL;DR

Ubuntu stores user data in /etc/passwd and group data in /etc/group
Use getent passwd or cat /etc/passwd to list all users
Use getent group or cat /etc/group to list all groups
The id command shows a user’s UID, GID, and group memberships in one shot
The who and w commands reveal who’s currently logged into your system
Group membership determines what files and resources a user can access

Understanding How Ubuntu Tracks Users and Groups

Before we dive into commands, it helps to understand the underlying system. Ubuntu, like most Linux distributions, stores account information in plain-text files that live in the /etc directory.

For additional guidance on managing Ubuntu accounts and permissions, refer to the official Ubuntu user-management documentation.

The three key files are:

/etc/passwd : holds user account information
/etc/shadow : stores password hashes and password-aging information. It is normally accessible only to the root user or privileged system processes.
/etc/group : stores group definitions

You can open and read all three of these files right now. They follow a predictable format, and once you understand that format, you’ll have much more control over how Ubuntu manages access to your system.

How Ubuntu Defines a User Account

Every user on an Ubuntu system has a corresponding line in /etc/passwd.

Here’s an example of a typical entry:

LOGINNAME:x:1001:1001:FULLNAME,,,:/home/DIRECTORY:/bin/bash

That’s one line. Let me break it down field by field:

The UID (User ID) is what Ubuntu actually uses internally to track users, not the username.

Root always has UID 0. System services get UIDs in the 1–999 range typically, while regular users start from 1000 onwards.

The GID (Group ID) tells you which primary group the user belongs to. But here’s something that trips up many beginners: a user can belong to multiple groups. The primary group is just the one that’s assigned by default when creating files.

Read Full Article: https://serveravatar.com/list-users-and-groups-in-ubuntu