SysAdmin

Simplifying Linux System Administration with Webmin

George Whittaker — Thu, 25 Jul 2024 16:00:00 +0000

Introduction

Linux system administration encompasses managing the software and hardware of Linux systems, which can be complex, especially for those new to Linux or managing multiple systems. Fortunately, Webmin, a web-based interface, simplifies many of the routine tasks involved in maintaining a healthy Linux system. This article explores how Webmin can be an invaluable tool for beginners and seasoned system administrators alike by providing a straightforward approach to managing Linux configurations through a simple browser interface.

What is Webmin?

Webmin is an open-source web-based interface for system administration for Unix-like systems, including Linux. Developed by Jamie Cameron, Webmin removes the necessity for manually editing Unix configuration files like /etc/passwd, and lets you manage a system from the console or remotely. It extends its functionality by offering modules that manage various services, from web servers to updates.

Key Features and Benefits

User-friendly Interface: Manage services through a graphical user interface without needing deep command-line knowledge.
Modular Design: Customize its functionality with various standard and third-party modules.
Accessibility: Access your servers from anywhere through a standard web browser.
Flexibility: Compatible with many Unix systems and distributions including Ubuntu, CentOS, and Debian.

Getting Started with Webmin

Webmin can be installed on virtually any machine running Unix-like systems, but it's typically run on servers. Minimal hardware requirements make it ideal for both old and new hardware.

Installation methods vary slightly between Linux distributions. Here's how to install Webmin on Ubuntu and CentOS.

Ubuntu Installation

Update your package list: sudo apt update
Install dependencies: sudo apt install wget perl

Download the Webmin .deb package using wget:

wget http://prdownloads.sourceforge.net/webadmin/webmin_1.981_all.deb

Install the package:
sudo dpkg -i webmin_1.981_all.deb
If there are missing dependencies, fix them:
sudo apt-get install -f

CentOS Installation

Add the Webmin repository:
sudo vi /etc/yum.repos.d/webmin.repo
And add the following lines:
[Webmin] name=Webmin Distribution Neutral # Replace `mirror` with the closest mirror site baseurl=http://download.webmin.com/download/yum enabled=1 gpgcheck=1 gpgkey=http://www.webmin.com/jcameron-key.asc

Go to Full Article

Experts Attempt to Explain DevOps--and Almost Succeed

Bryan Lunduke — Wed, 07 Aug 2019 20:00:00 +0000

by Bryan Lunduke

What is DevOps? How does it relate to other ideas and methodologies within software development? Linux Journal Deputy Editor and longtime software developer, Bryan Lunduke isn't entirely sure, so he asks some experts to help him better understand the DevOps phenomenon.

The word DevOps confuses me.

I'm not even sure confuses me quite does justice to the pain I experience—right in the center of my brain—every time the word is uttered.

It's not that I dislike DevOps; it's that I genuinely don't understand what in tarnation it actually is. Let me demonstrate. What follows is the definition of DevOps on Wikipedia as of a few moments ago:

DevOps is a set of software development practices that combine software development (Dev) and information technology operations (Ops) to shorten the systems development life cycle while delivering features, fixes, and updates frequently in close alignment with business objectives.

I'm pretty sure I got three aneurysms just by copying and pasting that sentence, and I still have no clue what DevOps really is. Perhaps I should back up and give a little context on where I'm coming from.

My professional career began in the 1990s when I got my first job as a Software Test Engineer (the people that find bugs in software, hopefully before the software ships, and tell the programmers about them). During the years that followed, my title, and responsibilities, gradually evolved as I worked my way through as many software-industry job titles as I could:

Automation Engineer: people that automate testing software.
Software Development Engineer in Test: people that make tools for the testers to use.
Software Development Engineer: aka "Coder", aka "Programmer".
Dev Lead: "Hey, you're a good programmer! You should also manage a few other programmers but still code just as much as you did before, but, don't worry, we won't give you much of a raise! It'll be great!"
Dev Manager: like a Dev Lead, with less programming, more managing.
Director of Engineering: the manager of the managers of the programmers.
Vice President of Technology/Engineering: aka "The big boss nerd man who gets to make decisions and gets in trouble first when deadlines are missed."

During my various times with fancy-pants titles, I managed teams that included:

Go to Full Article

My Favorite Infrastructure

Kyle Rankin — Wed, 07 Aug 2019 15:45:00 +0000

by Kyle Rankin

Take a tour through the best infrastructure I ever built with stops in architecture, disaster recovery, configuration management, orchestration and security.

Working at a startup has many pros and cons, but one of the main benefits over a traditional established company is that a startup often gives you an opportunity to build a completely new infrastructure from the ground up. When you work on a new project at an established company, you typically have to account for legacy systems and design choices that were made for you, often before you even got to the company. But at a startup, you often are presented with a truly blank slate: no pre-existing infrastructure and no existing design choices to factor in.

Brand-new, from-scratch infrastructure is a particularly appealing prospect if you are at a systems architect level. One of the distinctions between a senior-level systems administrator and architect level is that you have been operating at a senior level long enough that you have managed a number of different high-level projects personally and have seen which approaches work and which approaches don't. When you are at this level, it's very exciting to be able to build a brand-new infrastructure from scratch according to all of the lessons you've learned from past efforts without having to support any legacy infrastructure.

During the past decade, I've worked at a few different startups where I was asked to develop new infrastructure completely from scratch but with high security, uptime and compliance requirements, so there was no pressure to cut corners for speed like you might normally face at a startup. I've not only gotten to realize the joy of designing new infrastructure, I've also been able to do it multiple times. Each time, I've been able to bring along all of the past designs that worked, leaving behind the bits that didn't, and updating all the tools to take advantage of new features. This series of infrastructure designs culminated in what I realize looking back on it is my favorite infrastructure—the gold standard on which I will judge all future attempts.

In this article, I dig into some of the details of my favorite infrastructure. I describe some of the constraints around the design and explore how each part of the infrastructure fits together, why I made the design decisions I did, and how it all worked. I'm not saying that what worked for me will work for you, but hopefully you can take some inspiration from my approach and adapt it for your needs.

Go to Full Article

Bare-Bones Monitoring with Monit and RRDtool

Andy Carlson — Thu, 21 Mar 2019 12:00:00 +0000

by Andy Carlson

How to provide robust monitoring to low-end systems.

When running a critical system, it's necessary to know what resources the system is consuming, to be alerted when resource utilization reaches a specific level and to trend long-term performance. Zabbix and Nagios are two large-scale solutions that monitor, alert and trend system performance, and they each provide a rich user interface. Due to the requirements of those solutions, however, dedicated hardware/VM resources typically are required to host the monitoring solution. For smaller server implementations, options exist for providing basic monitoring, alerting and trending functionality. This article shows how to accomplish basic and custom monitoring and alerting using Monit. It also covers how to monitor long-term trending of system performance with RRDtool.

Initial Monit Configuration

On many popular Linux distros, you can install Monit from the associated software repository. Once installed, you can handle all the configuration with the monitrc configuration file. That file generally is located within the /etc directory structure, but the exact location varies based on your distribution.

The config file has two sections: Global and Services. The Global section allows for custom configuration of the Monit application. The Monit service contains a web-based front end that is fully configurable through the config file. Although the section is commented out by default, you can uncomment items selectively for granular customization. The web configuration block looks like this:


set httpd port 2812 and
    use address localhost
    allow localhost
    allow admin:monit

The first line sets the port number where you can access Monit via web browser. The second line sets the hostname (the HTTP Host header) that's used to access Monit. The third line sets the host from which the Monit application can be accessed. Note that you also can do this using a local firewall access restriction if a firewall is currently in place. The fourth line allows the configuration of a user name/password pair for use when accessing Monit. There's also a section that allows SSL options for encrypted connections to Monit. Although enabling SSL is recommended when passing authentication data, you also could reverse-proxy Monit through an existing web server, such as nginx or Apache, provided SSL is already configured on the web server. For more information on reverse-proxying Monit through Apache, see the Resources section at the end of this article.

The next items you need to enable deal with configuring email alerts. To set up the email server through which email will be relayed to the recipient, add or enable the following line:

Go to Full Article

Redefining the Landscape of System Monitoring: an Interview with Pulseway's Founder

Petros Koutoupis — Fri, 25 Jan 2019 13:15:15 +0000

by Petros Koutoupis

Pulseway provides a product of the same name that's built to enable IT personnel and give them the ability to monitor, manage and automate their systems and the tasks or applications that they host. And, the best part is that they can do all of these things anywhere and everywhere, from their pockets. In fact, I wrote about Pulseway once before, so check out that article for an introduction.

Pulseway is the Swiss Army knife of IT management, all accessible from your fingertips. You don't need to be glued to physical computer or connected to your employer's network. You are able to manage everything from either a web browser or mobile device—all you need is internet access.

I recently sat down with the founder and CEO of Pulseway, Marius Mihale, to ask him not only about exciting new things going on with the company, but also to find out where the company is heading.

Petros Koutoupis: Please, tell us a bit about yourself.

Marius Mihale: I am the Founder and CEO of Pulseway. I created both the software and solution about eight years ago. I initially designed the product with the goal of making the lives of IT administrators easier. It all started when I was attempting to shut down a server remotely but could not find a mobile application to aid me in this. This is how Pulseway was born. And while users can also access the same administration functions via a web browser and through our website, our core application is the mobile app: you can monitor Windows, Linux and Mac OS alongside various applications from your mobile device and take the necessary actions as they are needed.

PK: What has the demand been for such a solution?

MM: In 2011, we released a trial version of our product and almost immediately received a lot of wonderful feedback from the industry. It was this feedback that helped us shape the application we have today. Today, there are more than 300K registered free user accounts and more than 4,500 paid business and managed service provider (MSP) accounts worldwide—more specially, in both Europe and the United States.

PK: How has the IT management landscape evolved in the past year?

MM: Most of the actions we take and the features we implement are based on the needs of our users. We pay careful attention to our customer feedback and requests. And we implement a lot of this feedback, with simplicity in mind.

Go to Full Article

Weekend Reading: Sysadmin 101

Kyle Rankin — Sat, 08 Dec 2018 18:27:16 +0000

by Kyle Rankin

This series covers sysadmin basics. The first article explains how to approach alerting and on-call rotations as a sysadmin. In the second article, I discuss how to automate yourself out of a job, and in the third, I explain why and how you should use tickets. The fourth article covers some of the fundamentals of patch management under Linux, and the fifth and final article describes the overall sysadmin career path and the attributes that might make you a "senior sysadmin" instead of a "sysadmin" or "junior sysadmin", along with some tips on how to level up.

Sysadmin 101: Alerting

In this first article, I cover on-call alerting. Like with any job title, the responsibilities given to sysadmins, DevOps and Site Reliability Engineers may differ, and in some cases, they may not involve any kind of 24x7 on-call duties, if you're lucky. For everyone else, though, there are many ways to organize on-call alerting, and there also are many ways to shoot yourself in the foot.

Sysadmin 101: Automation

Here we cover systems administrator fundamentals. These days, DevOps has made even the job title "systems administrator" seem a bit archaic, much like the "systems analyst" title it replaced. These DevOps positions are rather different from sysadmin jobs in the past. They have a much larger emphasis on software development far beyond basic shell scripting, and as a result, they often are filled by people with software development backgrounds without much prior sysadmin experience. In the past, a sysadmin would enter the role at a junior level and be mentored by a senior sysadmin on the team, but in many cases currently, companies go quite a while with cloud outsourcing before their first DevOps hire. As a result, the DevOps engineer might be thrust into the role at a junior level with no mentor around apart from search engines and Stack Overflow posts.

Go to Full Article

Travel Laptop Tips in Practice

Kyle Rankin — Wed, 21 Nov 2018 13:00:00 +0000

by Kyle Rankin

It's one thing to give travel advice; it's another to follow it.

In past articles, I've written about how to prepare for a vacation or other travel when you're on call. And, I just got back from a vacation where I put some of those ideas into practice, so I thought I'd write a follow-up and give some specifics on what I recommended, what I actually did and how it all worked.

Planning for the Vacation

The first thing to point out is that this was one of the first vacations in a long time where I was not on call, directly or indirectly. In my long career as a sysadmin responsible for production infrastructure, I've almost always been on call (usually indirectly) when on vacation. Even if someone else was officially taking over on-call duties while I was away, there always was the risk that a problem would crop up where they would need to escalate up to me. Often on my vacations something did blow up to the point that I needed to get involved. I've now transitioned into more of a management position, so the kinds of emergencies I face are much different.

I bring up the fact that I wasn't on an on-call rotation not because it factored into how I prepared for the trip, but because, generally speaking, it didn't factor in except that I didn't have to go to as extreme lengths to make sure everyone knew how to contact me in an emergency. Even though I wasn't on call, there still was a chance, however remote, that some emergency could pop up where I needed to help. And, an emergency might require that I access company resources, which meant I needed to have company credentials with me at a minimum. I imagine for most people in senior-enough positions that this would also be true. I could have handled this in a few ways:

Hope that I could access all the work resources I might need from my phone.
Carry a copy of my password manager database with me.
Put a few select work VMs on my travel laptop.

I chose option number 3, just to be safe. Although I'm not superstitious, I still figured that if I were prepared for an emergency, there was a better chance one wouldn't show up (and I was right). At the very least, if I were well prepared for a work emergency, if even a minor problem arose, I could respond to it without a major inconvenience instead of scrambling to build some kind of MacGyver-style work environment out of duct tape and hotel computers.

Selecting the Travel Computer

As I've mentioned in previous articles, I recommend buying a cheap, used computer for travel. That way, if you lose it or it gets damaged, confiscated or stolen, you're not out much money. I personally bought a used Acer Parrot C710 for use as a travel computer, because it's small, cheap and runs QubesOS pretty well once you give it enough RAM.

Go to Full Article

Schedule One-Time Commands with the UNIX at Tool

Kyle Rankin — Mon, 19 Nov 2018 12:30:00 +0000

by Kyle Rankin

Cron is nice and all, but don't forget about its cousin at.

When I first started using Linux, it was like being tossed into the deep end of the UNIX pool. You were expected to use the command line heavily along with all the standard utilities and services that came with your distribution. At lot has changed since then, and nowadays, you can use a standard Linux desktop without ever having to open a terminal or use old UNIX services. Even as a sysadmin, these days, you often are a few layers of abstraction above some of these core services.

I say all of this to point out that for us old-timers, it's easy to take for granted that everyone around us innately knows about all the command-line tools we use. Yet, even though I've been using Linux for 20 years, I still learn about new (to me) command-line tools all the time. In this "Back to Basics" article series, I plan to cover some of the command-line tools that those new to Linux may never have used before. For those of you who are more advanced, I'll spread out this series, so you can expect future articles to be more technical. In this article, I describe how to use the at utility to schedule jobs to run at a later date.

at vs. Cron

at is one of those commands that isn't discussed very much. When people talk about scheduling commands, typically cron gets the most coverage. Cron allows you to schedule commands to be run on a periodic basis. With cron, you can run a command as frequently as every minute or as seldom as once a day, week, month or even year. You also can define more sophisticated rules, so commands run, for example, every five minutes, every weekday, every other hour and many other combinations. System administrators sometimes will use cron to schedule a local script to collect metrics every minute or to schedule backups.

On the other hand, although the at command also allows you to schedule commands, it serves a completely different purpose from cron. While cron lets you schedule commands to run periodically, at lets you schedule commands that run only once at a particular time in the future. This means that at fills a different and usually more immediate need from cron.

Using at

At one point, the at command came standard on most Linux distributions, but these days, even on servers, you may find yourself having to install the at package explicitly. Once installed, the easiest way to use at is to type it on the command line followed by the time you want the command to run:

Go to Full Article

Why Your Server Monitoring (Still) Sucks

Mike Julian — Thu, 01 Nov 2018 15:25:46 +0000

by Mike Julian

Five observations about why your your server monitoring still stinks by a monitoring specialist-turned-consultant.

Early in my career, I was responsible for managing a large fleet of printers across a large campus. We're talking several hundred networked printers. It often required a 10- or 15-minute walk to get to some of those printers physically, and many were used only sporadically. I didn't always know what was happening until I arrived, so it was anyone's guess as to the problem. Simple paper jam? Driver issue? Printer currently on fire? I found out only after the long walk. Making this even more frustrating for everyone was that, thanks to the infrequent use of some of them, a printer with a problem might go unnoticed for weeks, making itself known only when someone tried to print with it.

Finally, it occurred to me: wouldn't it be nice if I knew about the problem and the cause before someone called me? I found my first monitoring tool that day, and I was absolutely hooked.

Since then, I've helped numerous people overhaul their monitoring systems. In doing so, I noticed the same challenges repeat themselves regularly. If you're responsible for managing the systems at your organization, read on; I have much advice to dispense.

So, without further ado, here are my top five reasons why your monitoring is crap and what you can do about it.

1. You're Using Antiquated Tools

By far, the most common reason for monitoring being screwed up is a reliance on antiquated tools. You know that's your issue when you spend too much time working around the warts of your monitoring tools or when you've got a bunch of custom code to get around some major missing functionality. But the bottom line is that you spend more time trying to fix the almost-working tools than just getting on with your job.

The problem with using antiquated tools and methodologies is that you're just making it harder for yourself. I suppose it's certainly possible to dig a hole with a rusty spoon, but wouldn't you prefer to use a shovel?

Great tools are invisible. They make you more effective, and the job is easier to accomplish. When you have great tools, you don't even notice them.

Maybe you don't describe your monitoring tools as "easy to use" or "invisible". The words you might opt to use would make my editor break out a red pen.

This checklist can help you determine if you're screwing yourself.

Go to Full Article

Have a Plan for Netplan

Shawn Powers — Tue, 16 Oct 2018 13:08:08 +0000

by Shawn Powers

Ubuntu changed networking. Embrace the YAML.

If I'm being completely honest, I still dislike the switch from eth0, eth1, eth2 to names like, enp3s0, enp4s0, enp5s0. I've learned to accept it and mutter to myself while I type in unfamiliar interface names. Then I installed the new LTS version of Ubuntu and typed vi /etc/network/interfaces. Yikes. After a technological lifetime of entering my server's IP information in a simple text file, that's no longer how things are done. Sigh. The good news is that while figuring out Netplan for both desktop and server environments, I fixed a nagging DNS issue I've had for years (more on that later).

The Basics of Netplan

The old way of configuring Debian-based network interfaces was based on the ifupdown package. The new default is called Netplan, and although it's not terribly difficult to use, it's drastically different. Netplan is sort of the interface used to configure the back-end dæmons that actually configure the interfaces. Right now, the back ends supported are NetworkManager and networkd.

If you tell Netplan to use NetworkManager, all interface configuration control is handed off to the GUI interface on the desktop. The NetworkManager program itself hasn't changed; it's the same GUI-based interface configuration system you've likely used for years.

If you tell Netplan to use networkd, systemd itself handles the interface configurations. Configuration is still done with Netplan files, but once "applied", Netplan creates the back-end configurations systemd requires. The Netplan files are vastly different from the old /etc/network/interfaces file, but it uses YAML syntax, and it's pretty easy to figure out.

The Desktop and DNS

If you install a GUI version of Ubuntu, Netplan is configured with NetworkManager as the back end by default. Your system should get IP information via DHCP or static entries you add via GUI. This is usually not an issue, but I've had a terrible time with my split-DNS setup and systemd-resolved. I'm sure there is a magical combination of configuration files that will make things work, but I've spent a lot of time, and it always behaves a little oddly. With my internal DNS server resolving domain names differently from external DNS servers (that is, split-DNS), I get random lookup failures. Sometimes ping will resolve, but dig will not. Sometimes the internal A record will resolve, but a CNAME will not. Sometimes I get resolution from an external DNS server (from the internet), even though I never configure anything other than the internal DNS!

Go to Full Article