In the Beginning
Founded approximately 15 years ago, the Professional Linux User Group (ProLUG) began as a vision of Het Tanis, known by his community alias 'Scott Champine.' Het identified the need for an informal yet structured space where Linux professionals could share knowledge, collaborate, and grow together. What started as local in-person meetups quickly gained traction, thanks to the increasing demand for open-source collaboration and the widespread adoption of Linux in both enterprises and personal projects.
Why ProLUG Started
ProLUG was born out of the recognition that Linux professionals often face challenges that are best solved through peer collaboration and hands-on experience. The community’s founding principles were rooted in creating an environment where newcomers could learn from experienced professionals, and seasoned users could gain exposure to advanced topics and emerging technologies. Its core mission was simple yet impactful: to provide continuous growth opportunities in Linux system administration, automation, and cloud technologies.
Some of the key motivations behind ProLUG's formation include:
- Peer Support: Helping members solve technical challenges through discussion and advice from experts.
- Knowledge Sharing: Encouraging open sharing of tips, tricks, configurations, and scripts related to Linux and open-source tools.
- Hands-on Learning: Providing access to practical labs, exercises, and real-world scenarios for hands-on training.
- Community Mentorship: Offering a space for members to mentor and be mentored by others in different stages of their careers.
- Certification Prep: Assisting members in preparing for recognized industry certifications.
The Expansion into an Online Community
While initially focused on local in-person meetings, ProLUG embraced online platforms to extend its reach globally. The switch to a virtual model enabled:
- Global Networking: Professionals and enthusiasts from around the world could now connect, learn, and collaborate without geographical limitations.
- 24/7 Discussion: Via platforms like Discord, members could share insights, discuss Linux problems, and exchange ideas anytime, anywhere.
- Greater Diversity: The online expansion diversified the member base, incorporating individuals from various industries and technical backgrounds, creating a rich environment for problem-solving.
Interactive Labs and Training Programs
One of ProLUG’s most successful expansions has been its focus on interactive, hands-on labs. To bridge the gap between theory and practice, Het Tanis launched a series of labs on platforms like Killercoda, covering a variety of topics including:
- Linux Essentials and System Administration
- Ansible Automation
- Kubernetes and Container Orchestration
- Security and Network Hardening
With over 50 interactive labs available and more being continuously developed, members benefit from practical scenarios that simulate real-world challenges. The labs cater to beginners, intermediates, and experts, ensuring everyone has something to gain.
Certification and Career Development
In 2024, ProLUG launched its first structured certification course: Enterprise Linux Administration. This program was designed to provide a comprehensive curriculum covering topics such as:
- Advanced Linux system configuration
- Enterprise networking and services
- Security management
- Scripting and automation
The first cohort of graduates successfully completed the program in January 2025, marking a major milestone in ProLUG’s commitment to professional development. Many graduates have reported success stories, such as landing new jobs, securing promotions, or gaining confidence in their Linux expertise.
What is a User Group?
A user group is a community of individuals who come together to share common interests, typically in a specific area of technology, such as Linux. These groups can be local or online and serve as platforms for:
- Collaboration: Members work together to troubleshoot, build projects, and share experiences.
- Networking: Opportunities to connect with professionals, mentors, and employers within the field.
- Learning: Workshops, presentations, and discussions that cover new and emerging technologies.
- Career Growth: Access to resources, training programs, and job opportunities.
ProLUG is a prime example of how a user group can grow beyond its initial purpose, evolving into a vibrant global community with practical learning opportunities and real-world outcomes.
Success Stories
Being part of ProLUG has proven highly beneficial for many members, with success stories ranging from career advancements to personal growth:
- Job Opportunities: Members have found jobs in system administration, DevOps, and cloud engineering roles through networking within ProLUG.
- Certifications: Many members have successfully obtained Linux-related certifications, including RHCSA, RHCE, and LFCS, using ProLUG’s resources and mentorship programs.
- Skill Development: Through interactive labs and group discussions, members have honed skills in automation (Ansible), scripting (Bash, Python), containerization (Docker, Kubernetes), and more.
- Mentorship Relationships: Senior professionals have mentored newcomers, creating a cycle of continuous learning and knowledge sharing.
Current Milestones
- 3,000+ Members: ProLUG’s global community continues to grow rapidly, attracting Linux enthusiasts and professionals from various backgrounds.
- 50+ Interactive Labs: Covering diverse topics, from basic Linux administration to advanced enterprise systems management.
- Ongoing Training Programs: Continuous updates to certification preparation courses, interactive workshops, and guided lab exercises.
ProLUG’s commitment to fostering a collaborative environment has made it a go-to community for anyone interested in Linux. Whether you're a beginner looking to learn the basics or an experienced professional aiming to advance your career, ProLUG offers a pathway to success.
Each course run through the Professional Linux Users Group (ProLUG) allows you to earn a certification upon completion.
Certificates are awarded to those who complete the course within the timeframe that it is being run through the ProLUG Discord.
- To see when courses are running, join the ProLUG Discord server and check the Events section.
If you aim to earn the certification for completing this course, you must follow the guidelines set forth in this document.
There are four main components to earning the certification.
Worksheet Completion
Each unit has a corresponding worksheet.
On this worksheet are discussion questions, terms/definitions, optional "digging
deeper" sections, and reflection questions.
These worksheets must be filled out and kept until the end of the course.
Upon reaching the end, they are to be submitted to the instructor (Scott Champine).
Worksheet Submission Format
The format in which you submit these worksheets is up to you.
Some students prefer to keep them in a GitHub repository, others prefer to just keep them as files on their machines and submit via email.
Discussion Questions
Each unit's worksheet contains multiple discussion questions.
Each discussion question has its own thread in the ProLUG Discord server, in the
#course-discussion-posts forum channel.
To qualify for certification, you must:
- Post your answer to each discussion question in the correct thread.
- Respond to another student's answer in the same thread.
The goal of this is not to create busywork, but to spark discussions and see things from other points of view.
Lab Completion
Each unit has a lab that is to be completed.
The labs, like the worksheets, should be also completed and saved until the end of the course.
These labs should be submitted to the instructor along with the worksheets in the same format of your choice.
Final Project
Each ProLUG course has students complete a capstone project.
This is a requirement for earning a ProLUG course certification.
The project must meet the standards set forth in the Final Project Outline (or otherwise be approved by the instructor, Scott Champine).
The Professional Linux Users Group (ProLUG) provides a set of requirements and guidelines to contribute to this project. Below are steps to ensure contributors are adhering to those guidelines and fostering a productive version control environment.
Table of Contents
- How to be a Successful Contributor
- Signing your Git Commits with SSH
- Syncing your Fork with the Upstream ProLUG Repo
- Basic Contribution Workflow
- Supporting Material
How to be a Successful Contributor
To be an effective contributor understanding Git, whether through the command line or an external tool, will be an important part of contributing. To this effect it is important that any individual who contributes to this project have a working understanding of committing, merging, and other fundamental Git workflows.
For clarity this project utilizes GitHub for remote repositories and CI/CD testing pipeline workflows. Git and GitHub are two separate entities where GitHub provides the hosting services and Git provides the version control.
Prospective contributors are directed to several resources should they feel their competency with Git or GitHub falls short:
Git documentation:
Git and GitHub video tutorials:
- ByteByteGo's Git Explained in 4 Minutes (4m)
- Fireship's How to use Git and Github (12m)
- freeCodeCamp's Git and GitHub Crash Course (1hr)
Signing your Git Commits with SSH
Contributors who elect to contribute through the command line will need to verify their identities before their commits can be accepted. This step is not required if contributors will be submitting changes via GitHub.com itself since users will have verified their identities with GitHub's own verification process.
To reiterate, individuals contributing via command line will need to sign their commits through SSH. Signing GitHub commits helps ProLUG validate incoming commits from trusted contributors that reside outside the GitHub ecosystem. It can be quite trivial to impersonate users on GitHub and it is in the best interest of the project and contributors to observe this security practice.
It should also be noted that GitHub supplies tools like GitHub CLI
that abstract away the process of signing and verifying commits from the command line.
GitHub provides a gh auth login function to facilitate the procedure which contributors
can employ without the necessary changes suggested below.
To Sign your Git Commits with SSH:
Generate an SSH key pair if you don't have one:
ssh-keygen -t ed25519
Add SSH public key ('.pub' suffix) to GitHub as "Signing Key".
* GitHub.com -> Profile -> Settings -> GPG and SSH Keys -> Add SSH Key -> Drop down -> Signing Key
Below is a bash script that will attempt to configure signing Git commits on a localhost:
#!/bin/bash
GH_USERNAME="YourUsername"
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global tag.gpgSign true
git config --global commit.gpgSign true
mkdir -p ~/.config/git
touch ~/.config/git/allowed_signers
echo "${GH_USERNAME} $(cat ~/.ssh/id_ed25519.pub)" > ~/.config/git/allowed_signers
git config --global gpg.ssh.allowedSignersFile ~/.config/git/allowed_signers
# Make a commit to verify
git log --show-signature -1
Make a commit after running those commands and then use git log --show-signature -1.
You should see something like Good "git" signature for <yourname> with ED25519 key SHA256:abcdef... if it worked.
Your commits should now be verified from your account. This helps us ensure that valid users are contributing to this project. Unverified commits will be scrutinized and likely discarded.
Syncing your Fork with the Upstream ProLUG Repo
In an effort to minimize merge conflicts we strongly suggest forks remain up to date with the original repository before committing changes. This will help us reduce pull request management overhead.
You can do this from the GitHub web UI easily with the Sync Fork button. If you want to do this from the terminal, you can add a new git remote called upstream.
git remote add upstream https://github.com/ProfessionalLinuxUsersGroup/pcae.git
Then, to sync your local fork with the original repo, do a git pull from the upstream remote.
git pull upstream main
This fork should now be up to date with the original upstream repository.
Basic Contribution Workflow
You'll create your own fork of the repository using the GitHub web UI, create a branch, make changes, push to your fork, then open a pull request.
Comment First
If you'd like to work on a specific worksheet or lab, please let us know first by commenting on the issue so you can be assigned to it. This way, other contributors can see that someone is already working on it.
This helps the repository maintainers and contributors attain a high degree of visibility and collaboration before merging changes.
Create a Fork
Go to the original repository link. Click on "Fork" on the top right. Now you'll have your own version of the repository that you can clone.
git clone git@github.com:YOUR_USERNAME/pcae.git
# Or, with https:
git clone https://github.com/YOUR_USERNAME/pcae.git
Clone the Fork to your Local Machine
Then you'll need to clone your fork down to your local machine in order to work on it.
git clone git@github.com:yourname/pcae.git
Create a New Branch
Whenever making changes contributors are highly encouraged to create a branch with an appropriate name. Switch to that branch, then make changes there.
For example, if you're working on the Unit 1 Worksheet:
git branch unit1-worksheet
git switch unit1-worksheet
# Or, simply:
git switch -c unit1-worksheet
Make changes to the u1ws.md.
Consider a few Useful Practices
The practices presented below are not required to contribute to the ProLUG course books but can streamline contributing to any project and are considered to some as best practice or incredibly useful when engaging in version control with Git.
Git Rebasing
Proper implementation of rebasing can leave a clean, and easily readable commit history for all concerned parties. Rebasing can also facilitate the management of branches and working directories in a notably active project.
The Git documentation provides a succinct explanation of its utility but also how it could potentially ruin a project and erase the work of other contributors.
Rebasing also plays a role in facilitating any commit reverts that may need to be made in the future. More on that will follow.
Git Rebasing documentation: https://git-scm.com/book/en/v2/Git-Branching-Rebasing
Commit Early, Often, and Squashing Commits
It is great practice to commit early, and often. This however can produce hard to read commits for repo maintainers and contributors. Squashing commits, which is a type of rebasing, can be utilized to compress a large number of commits made in a local repository before being pushed into a remote repository and eventual pull requests.
Below is an example of 4 local commits squashed into a single commit that was pushed remotely:
Squashing commits can improve readability, but its primary utility, especially for larger projects, may be in addressing an event where rolling back several commits due to a bug or test can be done with a single commit revert.
freeCodeCamp has a great write-up on this procedure. When done appropriately this can greatly facilitate the development process. Contributors are strongly encouraged to begin exploring these types of workflows if they never have.
Git Stashing
Another useful practice is to employ "stashing" uncommitted files in a local repository. This is useful in many contexts including stashing local changes to resolve recently introduced remote vs. local repo conflicts, or quickly switching working spaces.
Stashing effectively unstages any changes made in the local repo and saves them to be applied later. This can further help facilitate a rebase or merge before committing changes upstream for instance.
https://www.atlassian.com/git/tutorials/saving-changes/git-stash
https://git-scm.com/book/en/v2/Git-Tools-Stashing-and-Cleaning
Commit and Push your Changes
First make sure your forked repo is up-to-date with the original. Create your commit (make sure it's signed!), then push changes to your own fork on the new branch.
git commit -m "descriptive commit message"
git push origin unit1-worksheet
Comment your Changes
Before creating a pull request, make a comment on the issue containing your changes. We're doing this since the GitHub organization feature is paid and we are doing this for free, so there is only one person who is able to merge pull requests at the moment.
Create a Pull Request
Now you'll be able to go to the original repository link and go to the "Pull Requests" tab and create a new pull request.
Select your branch unit1-worksheet, and create a description and mention an issue by number (e.g., #5).
Supporting Material
Below are links to the necessary materials to build out the course templates:
- Look over the template pages wiki, or directly here:
Ancillary unit videos provided by Scott:
PDF and docs directly related to each Unit of the course:
It is strongly encouraged that contributors test their changes before making commits. To help facilitate this process a set of instructions and guidelines are provided below. These guidelines are by no means a requirement or the only set of procedures to locally develop on this project.
The examples, code, and commands provided below were developed using such technologies as containers, bash scripts, and more.
Build Dependencies
The ProLUG Linux Automation Engineering Course (pcae) utilizes mdBook (markdown Book), a friendly and popular markdown utility that quickly exports static web files for documentation or general website use cases.
Utilizing mdBook this course then deploys the exported web structure to a Git Pages workflow and runner that then produces an easily navigable website.
Below is the current workflow that deploys the Git Page for the course:
To achieve this deployment locally the following environment and dependencies are required:
-
A localhost, this could be a container, virtual machine, or local machine
-
The following packages installed on such machine:
- httpd or apache
- git
- mdBook binary
-
And a clone of a ProLUG repository
Building, Deploying, and Developing Locally
Below is a set of scripts that can quickly achieve this environment in an automated fashion.
These commands assume a root user. This script will update and upgrade host packages to
their latest versions, install git, curl, tar, gzip, grep and their dependencies if they aren't present,
attempt to pull down the latest fully compiled mdbook binary from the official mdBook GitHub repository, boot
up the local web server, process and produce the necessary .html files from the pcae source files, deploy
the website and necessary cleanup operations.
Outside of system packages all files will be localized to the /root/pcae directory on the container or machine.
APT frontends:
#!/bin/bash
apt-get update && apt-get -y install apache2 git curl tar gzip grep
cd && git clone https://github.com/ProfessionalLinuxUsersGroup/pcae && cd "$HOME"/pcae
VERSION="$(curl -sL https://github.com/rust-lang/mdBook/releases/latest | grep -Po -m 1 'v(?:\d\.){2}\d+')"
curl -sLO "https://github.com/rust-lang/mdBook/releases/download/"$VERSION"/mdbook-"$VERSION"-x86_64-unknown-linux-gnu.tar.gz"
tar xfz mdbook-"$VERSION"-x86_64-unknown-linux-gnu.tar.gz
rm -f mdbook-"$VERSION"-x86_64-unknown-linux-gnu.tar.gz
systemctl enable --now apache2
"$PWD"/mdbook build -d /var/www/html
systemctl restart apache2
DNF frontends:
#!/bin/bash
dnf install -y httpd git curl tar gzip grep
cd && git clone https://github.com/ProfessionalLinuxUsersGroup/pcae && cd $HOME/pcae
VERSION=$(curl -sL https://github.com/rust-lang/mdBook/releases/latest | grep -Po -m 1 'v(?:\d\.){2}\d+')
curl -sLO "https://github.com/rust-lang/mdBook/releases/download/"$VERSION"/mdbook-"$VERSION"-x86_64-unknown-linux-gnu.tar.gz"
tar xfz mdbook-"$VERSION"-x86_64-unknown-linux-gnu.tar.gz
rm -f mdbook-"$VERSION"-x86_64-unknown-linux-gnu.tar.gz
systemctl enable --now httpd
"$PWD"/mdbook build -d /var/www/html
systemctl restart httpd
The ProLUG Linux Administration Course website should now be available from your web browser either at http://localhost or its designated IP address.
From here you can use such commands from your localhost to implement changes:
cd {working pcae directory} #for example: /root/pcae or ~/pcae
$HOME/pcae/mdbook build -d /var/www/html
systemctl restart {httpd or apache}
These commands will switch your shell into the appropriate directory, execute the necessary cargo binaries located in its installed PATH, build the mdBook from any files that were changed, and then finally restart the web server.
From there you should be able to see any changes you have made are reflected.
Or send commands over to a networked container or machine:
Note: To minimize complexity and given the nature of commands over SSH, these commands will need to utilize absolute paths.
scp {working directory}/{targeted document} {TARGET_IP}:/root/pcae/src/{targeted document}
ssh {TARGET_IP} "cd /root/pcae && /root/pcae/mdbook build -d /var/www/html && systemctl restart httpd"
An example of the workflow after making changes:
scp src/development.md 172.16.15.8:/root/pcae/src/
ssh 172.16.15.8 "cd /root/pcae && /root/pcae/mdbook build -d /var/www/html && systemctl restart httpd"