DEV Community: Meghna Meghwani

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

GitHub vs Bitbucket vs GitLab: Complete Comparison Guide

Meghna Meghwani — Thu, 30 Jul 2026 06:08:25 +0000

GitHub vs Bitbucket vs GitLab is one of the most common comparisons developers make when choosing a Git hosting platform. If you’ve spent time developing software, you’ve heard all three names thrown around. GitHub, Bitbucket, and GitLab all store code, support version control, and play a key role in nearly every developer’s workflow.

But picking the wrong one for your team can create real friction. Maybe your CI/CD pipeline ends up overcomplicated because your platform’s built-in tools aren’t great. Maybe your security team is drowning in compliance reports because the platform doesn’t have the controls you need. Or maybe you’re just leaving money on the table by paying for features you never use.

This guide cuts through the noise. We’re going to compare these three platforms honestly, what’s genuinely good about each, where each one falls short, and which situations suit each one best. By the end, you’ll know exactly which platform fits your team.

TL;DR

GitHub remains the largest developer community with unmatched integrations, GitHub Copilot AI features, and a massive marketplace. Best for open-source projects, developer portfolios, and teams that prioritize community and ecosystem.
Bitbucket works best for teams already deep in the Atlassian ecosystem, Jira, Confluence, and the rest. Less compelling if you’re not already using Atlassian tools.
GitLab is an all-in-one DevOps platform with built-in CI/CD, security scanning, and compliance tools. Best for teams that want everything under one roof and don’t want to stitch together separate tools.
The right choice depends on your team size, workflow, budget, and whether you need built-in CI/CD or prefer to bring your own.

What These Platforms Actually Are and Why the Distinction Matters

Let’s level-set quickly. All three platforms are built on Git, the distributed version control system that tracks changes to your code over time. Without getting into the Git internals, what you need to know is that these platforms take Git and wrap it with features that make collaboration, code review, automation, and security easier at scale.

Nowadays, they’ve all evolved well beyond just being “places to store code”.

GitHub has GitHub Copilot and a massive Actions marketplace.
Bitbucket is the glue that holds Atlassian’s ecosystem together.
GitLab positions itself as a complete DevOps platform with security and compliance baked in.

Platform Overview: Where Each One Stands

GitHub

GitHub remains one of the most widely used platforms for version control and collaborative software development. Its massive developer community, extensive integrations, and AI-powered tools make it a preferred choice for both individual developers and large enterprises.

During my evaluation, GitHub was the quickest platform to get started with. Creating repositories, configuring branch protection, and enabling GitHub Actions required minimal setup, making it especially approachable for developers who want to move from code to deployment quickly.

Its polished interface and extensive documentation also reduced the learning curve compared to the other platforms.

Read Full Article: https://serveravatar.com/github-vs-bitbucket-vs-gitlab

How to Check and Upgrade WordPress Version Safely

Meghna Meghwani — Wed, 29 Jul 2026 07:27:39 +0000

Let me be direct: if you’re running an outdated version of WordPress right now, your site is a liability. I’m not trying to sound dramatic, but I’ve seen what happens when a critical vulnerability is discovered while someone is still using an older WordPress release. It isn’t pretty, hacked redirects, injected malware, and SEO rankings disappearing overnight. That’s why it’s essential to upgrade WordPress version regularly. Keeping your site up to date is one of the simplest and most effective ways to protect its security, performance, and stability.

The good news is that checking and upgrading your WordPress version is not complicated. There are multiple ways to do it, from a point-and-click dashboard to command-line tools for the automation-inclined. The method you choose doesn’t matter as much as the habit itself. What matters is that you actually do it.

This guide walks you through every way to check your current WordPress version and every way to upgrade it, including the ServerAvatar WordPress Toolkit for those who prefer not to touch code at all. I will also walk you through what to do before you upgrade, because skipping that step is the mistake most people make.

TL;DR

Why it matters: Outdated WordPress is the #1 entry point for site hacks
Check your version: Dashboard footer, source code, version.php file, WP-CLI, or ServerAvatar WordPress Toolkit
Upgrade options: One-click WordPress admin dashboard, WP-CLI, or ServerAvatar WordPress Toolkit
Never upgrade without a backup first
Test on staging before touching production

Why WordPress Version Updates Matter

WordPress ships major releases roughly three to four times a year, with security patches dropping even more frequently. Nowadays, the threat landscape has only intensified; automated exploit kits now actively scan for known vulnerabilities in outdated WordPress installations within hours of a patch being released. If you’re not updating, you’re leaving the door open.

But it’s not just about security. Newer WordPress versions bring meaningful performance improvements. WordPress 6.4 and 6.5 introduced significant query optimization and reduced database overhead. Staying current means your site runs faster without you having to do anything else. New block editor features, improved media handling, and accessibility improvements all stack up over time.

There’s also the compatibility angle. Plugin and theme developers follow WordPress core releases closely. The moment a popular plugin drops support for an older version, you either update WordPress or you lose access to that plugin’s updates, a forced choice nobody wants to make under pressure.

How to Check Your Current WordPress Version

You would think this is obvious, but I have worked with site owners who had no idea they were running WordPress 5.8 on a 2026 server. Here are the ways to check, from easiest to most technical.

1. Check from the WordPress Dashboard

This is the fastest method and requires no tools beyond your browser.

Log in to your WordPress admin panel.
Scroll to the Home section in the WordPress admin dashboard. You can see the version in the “At a Glance” widget.
It looks subtle, but that’s your answer.

Best for: Anyone with admin access to WordPress who wants a five-second check.

Read Full Article: https://serveravatar.com/upgrade-wordpress-version

How to Fix SSH Connection Refused Error

Meghna Meghwani — Tue, 28 Jul 2026 06:11:08 +0000

You have typed your command, hit Enter, expecting to connect to your server. Instead, you’re greeted with the frustrating SSH Connection Refused error rather than a welcoming shell prompt.

ssh: connect to host your-server port 22: Connection refused

That flat, unhelpful line is one of the most frustrating messages in server management. No explanation. No suggested fix. Just a door slammed in your face.

I have been there more times than I’d like to admit, particularly after spinning up new VPS instances where I’d forgotten to note the custom SSH port, or after a firewall rule I applied broader than intended cut off my own access.

The good news: SSH Connection Refused is almost always fixable in minutes once you know what to check. This guide walks through every real cause I have encountered in practice, with the exact commands that diagnose and resolve each one.

What this guide covers: the meaning behind the error, causes, step-by-step fixes, a prevention checklist, and the FAQs I actually hear from developers.

Who it’s for: anyone managing a Linux server, whether it’s your first VPS or your hundredth.

TL;DR

SSH Connection Refused means the server is actively rejecting your connection attempt
The most common causes: wrong port, service not running, firewall blocking, wrong credentials, and SSH not installed
Most fixes take under 5 minutes from your terminal
Always verify the fix by attempting to reconnect before assuming the problem is solved
Prevention: use non-default ports, configure fail2ban, and restrict SSH to specific IPs

What Does “SSH Connection Refused” Actually Mean?

Let’s be precise, because understanding the mechanics changes how you debug.

“Connection Refused” is TCP’s way of saying: I heard you, but I’m not accepting this connection. The server received your SYN packet, processed it, and sent back a RST (reset) flag. This is fundamentally different from a timeout (where the server never responds at all) or an authentication failure (where the server accepts the connection but rejects your credentials).

In SSH terms, this means the SSH daemon, sshd , either isn’t listening on the port you are targeting, isn’t running at all, or something network-level is intercepting the request before it reaches the daemon.

The practical difference matters: if you see “Connection Refused”, you at least know the server is reachable over the network. That’s useful diagnostic information.

If you want to learn more about how SSH works internally, including its configuration options and authentication process, the official OpenSSH documentation provides detailed explanations.

How to Diagnose SSH Connection Refused

Before fixing anything, verify. The most common mistake I see is jumping to conclusions, changing the SSH port when the problem was the firewall, or reinstalling SSH when the service just needed a restart.

Here’s the diagnostic sequence I follow, in order:

Step 1: Confirm the server is reachable at all

ping -c 3 your-server-ip

If ping fails, you have a network connectivity issue, possibly the server is down, or it’s on an unreachable network. That’s a different problem than Connection Refused.

Step 2: Check if the SSH port is reachable

nc -zv your-server-ip 22
# or if the port is non-standard:
nc -zv your-server-ip 2222

If this shows “Connection refused”, you have confirmation the problem is at the SSH layer.

Step 3: Use SSH verbose mode for more detail

ssh -v username@your-server-ip -p PORT

The -v flag (use -vvv for maximum verbosity) shows exactly where the connection attempt stalls.

This alone often points you directly to the problem.

Read Full Article: https://serveravatar.com/ssh-connection-refused

Linux File Permissions Explained: Read, Write, and Change Permissions

Meghna Meghwani — Sat, 25 Jul 2026 06:28:56 +0000

Linux file permissions are one of the first concepts every Linux user and system administrator needs to master. Every sysadmin has been burned by a permissions mistake at least once. Uploaded a script that won’t run. Moved a file you couldn’t overwrite. Set up a deployment hook that silently failed because the user running it didn’t have write access to the log directory. These aren’t exotic edge cases, they’re the daily friction of working on a Linux system.

Linux file permissions are the gatekeepers of everything that runs on your server. Get them right, and your applications work smoothly, your users can access what they need, and your server stays reasonably secure. Get them wrong, and you’re either locked out of your own files or handing out access like candy.

This guide cuts through the noise. You’ll learn exactly how Linux permission bits work, what each one actually does when you’re logged in, how to read the cryptic output of ls -l, and how to change permissions the right way using both symbolic and numeric chmod. Everything here is written from the perspective of someone who’s spent real hours on actual servers, not just quoting man pages.

TL;DR

Linux has three permission types: Read (r), Write (w), and Execute (x)
Permissions apply to three categories of users: Owner (u), Group (g), and Others (o)
The ls -l command shows permissions in a 10-character string like -rw-r--r--
Use chmod to change permissions, symbolic mode (u+x) or numeric mode (755)
Use chown and chgrp to change ownership
Common pitfalls: execute bit on directories, wrong group ownership, restrictive umask in production

Why Linux Permissions Matter More Than You Think

On a single-user laptop, permissions feel academic. On a server running multiple services, serving web traffic, and handling multiple users? Permissions are load-bearing infrastructure.

When a web server like Nginx runs, it typically operates under its own user, www-data on Ubuntu. The user account must have read permissions for the web root directory in order to serve website files. Your deployment script, running as a deploy user, needs write access to certain directories and execute access to deployment hooks. Your backup cron job, running as root, needs read access to everything but write access only to the backup volume.

Getting any one of these wrong breaks something silently. I’ve seen a Node.js app that kept crashing every night because a cron job was deleting its log directory, and the app didn’t have permission to recreate it. Permissions weren’t on anyone’s radar until the app started failing.

Understanding permissions also matters for security. The difference between chmod 777 and chmod 644 on a configuration file could be the difference between a server that’s yours and a server that’s been compromised. That’s not hyperbole, misconfigured permissions are a documented entry point for a wide range of attacks.

The Three Layers: Owner, Group, Others

Before you can understand what a permission means, you need to know who it’s being applied to. Linux splits access into three layers:

Owner (u)

The user who created the file. On a shared server, each user has their own home directory with files they own. The owner can change permissions on their own files, or take them away from themselves, which is a fun way to lock yourself out of something.

Group (g)

A group is a named collection of users. Instead of granting the same permission to five individual users one by one, you put them in a group and set permissions once. This is how most team-based server access works in practice.

Others (o)

Everyone else, users who aren’t the owner and aren’t in the owning group. “Others” permissions are your last line of defense. They’re what the world gets when someone with no account on your server tries to access your files.

The Three Permission Types Explained

Read (r or 4)

Read permission lets a user view a file’s contents. For a directory, read means listing the directory’s contents, you can see what files and subdirectories exist inside it, but you can’t enter it or access any of those files without additional permissions.

In practice, read on a directory is the permission that ls checks. Without it, ls returns a permission denied error even if you already know the directory exists.

Write (w or 2)

Write permission lets a user modify a file’s contents, add data, truncate it, rewrite it entirely. On a directory, write means you can create, delete, and rename files inside that directory.

Here’s the part that catches people: you need write permission on the directory itself to delete a file, not write permission on the file.

Execute (x or 1)

Execute permission is what makes a file run as a program or script. Without it, trying to run ./script.sh gives you a “permission denied” error, even if you own the file and have full read/write access.

For directories, execute has a different meaning: it allows access to the directory’s metadata and file contents. Without execute on a directory, you can’t cd into it or access any file inside it, even if you have read permission on those individual files.

Read Full Article: https://serveravatar.com/linux-file-permissions

How to Upload Image File in Laravel: Step-by-Step Guide

Meghna Meghwani — Thu, 23 Jul 2026 06:29:44 +0000

Every Laravel project I’ve worked on, whether it’s a client portal, a content management system, or an e-commerce setup, eventually needs one thing: upload image functionality. User avatars, product photos, blog thumbnails, and document attachments all rely on a reliable image upload system. The requirement shows up predictably, yet every time I reach for the documentation, I find myself piecing together bits from half a dozen sources.

Most tutorials cover the happy path. They show you the store() method, they mention enctype="multipart/form-data", and they call it done. But what about the messy parts? What happens when a user uploads a 12MB file and your server chokes? What if the validation rule passes locally but fails on your production VPS because of a misconfigured php.ini? And does your application actually handle filename collisions gracefully, or is it quietly overwriting files?

This guide is the tutorial I wish existed when I first needed to build robust image upload functionality in Laravel. We are going to cover the full picture, from setting up your database schema for image metadata, to building a form with client-side preview, to handling validation edge cases that tutorials skip, to the security considerations that actually matter in production.

TL;DR

Laravel handles image uploads through its filesystem layer, no extra packages needed for basic uploads
Store metadata (not just files) in your database: filename, path, MIME type, size, dimensions
Always validate on the server AND (for UX) on the client, server-side validation is non-negotiable
The storage:link command is still essential for serving files from the public web
Production concerns, PHP limits, disk permissions, filename collisions, are where most tutorials fall short
ServerAvatar’s built-in server management removes the permission and PHP config headaches from your deployment workflow

How Laravel’s File Storage Actually Works

Before we write a single line of code, it helps to understand what actually happens when a file upload reaches a Laravel application. This model will save you hours of debugging later.

When a user submits a multipart form, Laravel wraps the uploaded file in an UploadedFile object. This isn’t just the file data, it carries metadata: original filename, MIME type, file size, temporary path on disk, and more.

Laravel’s official documentation provides a detailed overview of uploaded files, storage disks, and filesystem operations if you want to explore advanced storage features.

Laravel then hands this object to the filesystem layer, which decides where to put the file based on your config/filesystems.php configuration. The two most relevant disks for image uploads are:

public – Files land in storage/app/public. These are accessible directly from the web, but only if you’ve run php artisan storage:link to create a symlink from public/storage to storage/app/public. This is the standard path for user-uploaded content you want publicly served.
local – Files land in storage/app. These are not web-accessible by default, which makes them suitable for files you want to control access to, think documents behind a paywall, or images served through a signed URL.

For most image upload use cases, profile photos, product images, gallery uploads, you will use public with the storage:link symlink. I will focus on that path in this guide.

Database Design: Storing Image Metadata the Right Way

Here’s a mistake I see constantly: they store the uploaded image path as a plain string column on the user or product table, and call it a day. This works until you need to display the image’s dimensions, filter by file size, or track which uploads are causing storage bloat.

Separate your concerns. Create a dedicated images table and use a polymorphic relationship. This way, any model in your application can have images, a user, a product, a blog post, without cluttering your main tables.

Schema::create('images', function (Blueprint $table) {
$table->id();
$table->morphs('imageable'); <em>// adds imageable_type and imageable_id</em>
$table->string('filename');
$table->string('path');
$table->string('mime_type');
$table->unsignedInteger('size'); <em>// in bytes</em>
$table->unsignedSmallInteger('width')->nullable();
$table->unsignedSmallInteger('height')->nullable();
$table->timestamps();
});

Storing image width and height can be useful for generating responsive images, validating aspect ratios, and creating thumbnails. You can easily retrieve these values during upload using PHP’s getimagesize() function.

The corresponding Eloquent model is straightforward:

class Image extends Model
{
protected $fillable = [
'filename', 'path', 'mime_type', 'size', 'width', 'height'
];

public function imageable()
{
return $this->morphTo();
}

public function url(): string
{
return asset('storage/' . $this->path . '/' . $this->filename);
}
}

What this gives you that a plain string column doesn’t: you can query images by size, filter by dimensions, eager-load them efficiently, and swap storage backends without touching your application code.

Read Full Article: https://serveravatar.com/laravel-image-upload