Looking for Project Ideas to Reach Professional Linux Skills

Tekle

Member
Joined
Aug 5, 2023
Messages
66
Reaction score
20
Credits
491
Hi everyone,

I’ve decided to move beyond being a regular Linux user and work toward a more professional level. Currently, I’m learning Bash scripting, and I’m also starting to explore virtualization. I’ve set up Ubuntu Server and Debian 13 as virtual machines using KVM.

One idea I have is to build some automation—for example, managing updates or installing packages across multiple servers from a single host machine, instead of logging into each one individually.

At the moment, I’m not entirely sure how to approach this. I would really appreciate any recommendations for learning resources, as well as suggestions for practical project ideas that could help me build skills and demonstrate them to potential employers.

Thank you in advance for your guidance!

Regards,
Tekle
 


 
I’ve decided to move beyond being a regular Linux user and work toward a more professional level. Currently, I’m learning Bash scripting, and I’m also starting to explore virtualization. I’ve set up Ubuntu Server and Debian 13 as virtual machines using KVM.

One idea I have is to build some automation—for example, managing updates or installing packages across multiple servers from a single host machine, instead of logging into each one individually.
I would recommend spending -a lot- of time on shell scripting, mainly because it's so just-plain-useful. I used to be a dyed-in-the-wool "C" guy and would definitely recommend learning that as well - in depth, not just a semester of class work. But with all the hoopla about python and rust (etc etc) there are some decent alternatives to C. I guess there are good alternatives to shell scripting as well but shell scripting is ubiquitous - unlike "bash" scripting, although there's certainly a place for that. I personally haven't written a non-trivial C program in a good many years but I'm forever writing both trivial and non-trivial shell scripts - admittedly, sometimes for projects that would be better served by other programming languages. It's what I do for fun but it's also really useful.

To move "toward a more professional level", don't just concentrate on the technical bits. Make sure you develop rock solid habits (like "don't embed 'magic numbers' in your code" and "write code that documents itself" and "document everything anyway"). And don't forget "people skills" - I hated it when I got dumped into an "application support" role (in addition to development work, of course!) but it eventually turned out to be really satisfying.
 
Thank you so much, @MikeRocor! These are extremely valuable lessons. “Write code that documents itself” and “people skills” are great advice. After reading your message, I reviewed one of my scripts that was not properly documented and now I understand why documentation is so important — particularly writing code that explains itself. This was a great lesson in using meaningful variable names that convey their purpose.
 
Thank you so much, @dos2unix, for sharing this Ansible tutorial! . I’m excited to go through your guide and deepen my understanding.
 
Thank you so much, @MikeRocor! These are extremely valuable lessons. “Write code that documents itself” and “people skills” are great advice. After reading your message, I reviewed one of my scripts that was not properly documented and now I understand why documentation is so important — particularly writing code that explains itself. This was a great lesson in using meaningful variable names that convey their purpose.
Yeah, after a goodly few years, I -still- can come back to a script I wrote less than a year ago and be baffled. It takes constant, habitual vigilance to keep yourself from using some new and clever technique without making note of what it actually does.

I came across this comic at xkcd.com while I was actually in the process of writing a script template that I could "use for all my future projects". My template, while excellent (IMHO), might lean a little toward the side of "overthinking it" :)

code_lifespan.png
 
Good idea to have a template. Could you please give me feedback to my template which I am working on?

#!/usr/bin/env bash

# =================================

# Author: Tekle
# Date : 24.03.2026
# Script name: template.sh
# Description : This is a template which is a masterpiece for any bash scripting I want write.
# Run/Usage: ./template.sh

#=====================================

clear

set -Eeuo pipefail

function_name()
{
local PARAMETER_A="$1"
local PARAMETER_B="$2"

if [ "$PARAMETER_A" -ne 0 ]

then
echo "$PARAMETER_A comment here "
return 0

else
echo "$PARAMETER_B comment here"
return 1

fi

}

# ================= FUNCTION CALL ==========
function_name

# ================= END ========================
 
I’ve decided to move beyond being a regular Linux user and work toward a more professional level. Currently, I’m learning Bash scripting, and I’m also starting to explore virtualization.
Toward what exactly are you leaning? system administration or coding?

For admin stuff I suggest to become package maintainer.
For coding start learning programming languages.
 
I wasn't trying to establish a format for various syntactic bits so much as trying to standardize how I handle common parts that I found myself rewriting for various new scripts.

For instance, the process of parsing arguments from the command line. I shamelessly borrowed a piece of code that handled arguments in a way that I liked, then enhanced it to make it simple to get a help screen with a list of available arguments.

Code:
#####
#
# ARGUMENTS
#
# process command line arguments - will override defaults -and- config file.
#   Note: Variable names except CONF have trailing underscores so they will
#         not be overridden by settings in the config file (if any).
#         After config file is loaded, these will be used to override any
#         conflicting parameters from the config file.
#   Credit: this method of processing command line arguments was lifted
#         directly from tinycore linux version 15.0 /etc/init.d/tcconfig
#         changing only variable name "i" to "ARG" and tabs to two spaces.
#         tnx to roberts and curaga
#
#<options>
ARGDATA=""
for ARG in ${*} ; do
  case $ARG in
    *=*)
      case $ARG in
        --conf=*)     CONF=${ARG#*=} ;;
        --debuglvl=*) DEBUGLVL_=${ARG#*=} ;;
        -h=*)         HELP_=${ARG#*=} ;;
        --help=*)     HELP_=${ARG#*=} ;;
      esac
    ;;
    *)
      case $ARG in
        -h)         HELP_=1 ;;
        --help)     HELP_=1 ;;
        *)          ARGDATA="${ARGDATA} ${ARG}"
      esac
    ;;
  esac
done
#</options>
#
#####

This is a fairly straight-forward way to process arguments. You just add arguments to be looked for with "name=value" pairs in the first section and stand-alone "flag" arguments in the second. Having the layout of it already written is handy - but what makes it super useful are those two comment lines that look like HTML tags:
#<options> and
#</options>
because there's a help function in the template that parses the code between those two tags. The script parses itself to produce a help screen listing valid arguments.

Code:
available_args(){
  # scan this script, ignoring all but the part between OPTSTART and OPTFINAL
  # and parse the enclosed case statement for arguments accepted
  OPTSTART="#<options>"
  OPTFINAL="#</options>"

  echo "The following lists valid command line arguments (    -h=/    ):"

  INOPTS=0
  CLVL=0
  cat "${SCRIPTPATH}" |while read REC ; do
    TERM1="`echo "${REC}" |awk '{print $1}'`"
    [ "${TERM1}" = "${OPTSTART}" ] && INOPTS=1
    [ "${TERM1}" = "${OPTFINAL}" ] && INOPTS=0
    [ "${INOPTS}" = 0 ] && continue

    [ "${TERM1}" = "case" ] && CLVL="`expr "${CLVL}" + 1`" && continue
    [ "${TERM1}" = "esac" ] && CLVL="`expr "${CLVL}" - 1`" && continue

    echo "${TERM1}" |grep -q "=" && TAG="name=value " || TAG="option flag"
    [ "${CLVL}" = "2" ] && [ "${TERM1}" != '*)' ] && echo -n "  ${TAG} : " && echo "${TERM1}" |cut -d')' -f1
  done
}

(I have to confess - not the most "readable" code I've ever written.)

In a working script that can take a bunch of different arguments, the arguments help system works like this:

Code:
tc@dolly:~$ tce-lode -h=/
#####
#
# /boo/bin/tce-lode
#
tce-lode version 1.3 - Tiny Core extension downloader
                                        by lem, 2016 - 2026
HELP=/

The following lists valid command line arguments (    -h=/    ):
  name=value  : --conf=*
  name=value  : --debuglvl=*
  name=value  : -h=*
  name=value  : --help=*
  name=value  : --krndir=*
  name=value  : --isodir=*
  name=value  : --tczdir=*
  name=value  : --dldir=*
  name=value  : --prot=*
  name=value  : --mirror=*
  name=value  : --corver=*
  name=value  : --relstat=*
  name=value  : --kernel=*
  name=value  : --arch=*
  name=value  : --filxs=*
  name=value  : --get-list=*
  option flag : -h
  option flag : --help
  option flag : --get-core
  option flag : --get-isos
#
#####
tc@dolly:~$

The template itself is about 300 lines, although about half of that is comments. The heavy comment count is because there's also a built in help function that produces help screens from the comments in the script code itself. There can be many help sections, depending upon the complexity of the script and how verbose I want to be. From the same script, the output of help index looks like this:
Code:
tc@dolly:~$ tce-lode -h=?
#####
#
# /boo/bin/tce-lode
#
tce-lode version 1.3 - Tiny Core extension downloader
                                        by lem, 2016 - 2026
HELP=?

Available help sections (    -h=?    ):
-h=1 :  primary help section                (    -h=1    or just    -h    )
-h=2 :  (Template) secondary help section                    (    -h=2    )
-h=3 :  (Template) help with help section                    (    -h=3    )
-h=4 :  tce-lode - common arguments                          (    -h=4    )
-h=Y :  Programming with script_template                     (    -h=Y    )
-h=Z :  Revision History help section                        (    -h=Z    )
-h=? :  help index (this list)
-h=/ :  list valid option arguments
-h=+ :  display all help sections
#
#####
tc@dolly:~$
 
Toward what exactly are you leaning? system administration or coding?

For admin stuff I suggest to become package maintainer.
For coding start learning programming languages.
I would like to be a Linux DevOps Engineer but at my current knowledge and skills, I might not find a job so decided to look for a job as linux adminstrator.
 
I would like to be a Linux DevOps Engineer but at my current knowledge and skills, I might not find a job so decided to look for a job as linux adminstrator.
Linux administrator will in addition have to know most scripting languages like python and bash and even ruby.
perl and similar are slowly going out of scope but still used.

You'll have hard time to find a job that's solely about devops.

Because Linux is so much connected to open source that means some skills with the code 1 way or another.
It's hard to be picky.
 
Thank you very much for sharing @MikeRocor . I am still a beginner in shell scripting, yours looks advanced.
It's not so much "advanced" as that I sometimes (too often?) program projects in shell script that maybe deserve some other language... but neither perl nor python are really my cup of tea. I suppose I should bite the bullet and spend some quality time with python.
 


Follow Linux.org

Staff online

Members online


Top