Aliases, in the context of the Linux shell, are commands you build yourself by packing them with combinations of other instructions that are too long or too hard to remember.

You create an alias by using the word alias, then the name of the command you want to create, an equal sign (=), and then the Bash command(s) you want your alias to run. For example, ls in its base form does not colorize its output, making it difficult to distinguish between directories, files, and links. You can build a new command that shows colors by making an alias like this:

alias lc='ls --color=auto'

where lc is the name you have picked for your new command. When creating aliases, be sure to check that the name you picked isn’t already in use, or you may override an existing command. In this case, lc stands for “list (with) color”. Notice there is no space in front of or behind the =. Finally, you have the regular Bash command(s) you want to run when lc is executed. In this case, the ls command with the --color option.

After defining your alias, every time you type lc, the contents of the current directory will be shown in color.

But, you may think, “my ls command already lists files in different colors!” That is because most Linux distros come with some aliases already set up for you.

Aliases you (probably) already have

Indeed, you can use the alias instruction without any options to see what aliases you already have. These will vary by distro, but some typical preset aliases are:

• alias ls='ls --color=auto': You already saw this one above. The auto modifier of the --color option tells ls to use color when standard output is connected to a terminal. That is, the output of ls is going to show up in a terminal window or a text screen, instead of, say, being piped to a file. Other alternatives for --color are always and never.
• alias cp='cp -i': The -i option stands for interactive. Sometimes, when you use cp you may inadvertently overwrite an existing file. By using the -i, cp will ask you before clobbering anything.
• alias free='free -m': Using -m with freeyou can see how much free memory you have and how much your applications are using in megabytes instead of the default bytes. This makes the output of free easier to read for a human.

There may be more (or less, or even none), but regardless of what your distribution comes with, you can always use the base form (vs. the aliased form) of a command with the \ modifier. For example:

\free

will execute free without the -m option, and

\ls

will execute ls without the --color=auto option.

If you want to get rid or modify the preset aliases forever, note that they live in the global .bashrc file which hangs out in our old haunt, the /etc/skel directory.

Aliases for muscle memory

Distro designers try their best to predict which aliases are going to be useful for you. But every user is different and comes from a different background. If you are new to GNU+Linux, it may be because you are coming from another system, and the basic commands vary from shell to shell. If you come from a Windows/MS-DOS background, you may want to define an alias like

alias dir='ls'

to list files or directories.

Likewise,

alias copy='cp'

alias move='mv'

may also come in handy, at least until you get used to Linux’s new lexicon.

The other problem occurs when mistakes become ingrained in your muscle memory, so you always mistype some words the same way. I, for instance, have great difficulty typing admnis-… adminsi-… A-D-M-I-N-I-S-T-R-A-T-I-ON (phew!) at speed. That is why some users create aliases like

alias sl='ls'

and

alias gerp='echo "You did it *again*!"; grep'

Although we haven’t formally introduced grep yet, in its most basic form, it looks for a string of characters in a file or a set of files. It’s one of those commands that you will tend to use A LOT once you get to grips with it, as those ingrained mistyping habits that force you to type the instruction twice every time get annoying really quickly.

Another thing to note in the gerp example is that it is not a single instruction, but two. The first one (echo "You did it *again*!") prints out a message reminding you that you misspelled the grep command, then there is a semicolon (;) that separates one instruction from the other. Finally, you’ve got the second command (grep) that does the actual grepping.

Using gerp on my system to search for the lines containing the word “alias” in /etc/skel/.bashrc, the output looks like this:

$ gerp -R alias /etc/skel/.bashrc

You did it *again*! alias ls='ls --color=auto' alias grep='grep --colour=auto' alias egrep='egrep --colour=auto' alias fgrep='fgrep --colour=auto' alias cp="cp -i"

alias df='df -h'

alias free='free -m'

alias np='nano -w PKGBUILD' alias more=less shopt -s expand_aliases

Running commands sequentially as part of an alias, or, even better, chaining commands so that one command can use the results coughed up by another, is getting us perilously close to Bash scripting. This has been in the making of this series for quite some time, and we’ll start covering it in the very next article.

For the time being, if you want to get rid of an alias you temporarily set up in a running terminal, use the unalias command:

unalias gerp

If you want to make your aliases permanent, you can drop them into the .bashrc file you have in your home directory. This is the same thing we did with custom environment variables in last week’s article.

See you next time!

Hey @Marvel, we heard about Tony Stark. As we know, the first thing you should do is listen in mission control for “@Avengers, we have a problem.” But if he can’t communicate, then we recommend ground teams use all resources to scan the skies for your missing man pic.twitter.com/zavXrsPljq

— NASA (@NASA) December 9, 2018

Appreciate any help you can provide ?

— Marvel Studios (@MarvelStudios) December 10, 2018

The THermal Operations and Resource (THOR) officer is truly one of Mission Control’s mightiest heroes. They ensure the operation of multiple @Space_Station subsystems which collect, distribute & reject heat from critical equipment and payloads for the success of the mission

— NASA (@NASA) December 9, 2018

Following the sales data estimates for the Japanese release of Super Smash Bros. Ultimate, Famitsu has now published official sales numbers confirming the game sold exactly 1,238,358 million copies in its launch week. This figure reportedly does not include digital sales.

As we noted previously, this makes Ultimate the biggest Nintendo-published game launch in Japan ever, not including the Pokémon series. It’s also the best debut for the Smash series in Japan and the highest opening week for a Switch game. Ultimate also improved Nintendo’s hybrid console sales last week. Famitsu said the system shifted 278,313 units compared to the previous week when it sold 107,450 units. This has helped domestic Switch sales surpass the six million mark.

Compared to existing Switch launch sales, Ultimate has smashed the competition. Last month’s Pokémon: Let’s Go, Pikachu! and Let’s Go, Eevee! sold 552,000 copies locally and the month before this Super Mario Party sold 131,000 copies on release. In 2017, Splatoon 2 shifted 631,000 copies at launch and Super Mario Odyssey followed this up with 514,000 sales.

The article How to Build a Netboot Server, Part 1 showed you how to create a netboot image with a “liveuser” account whose home directory lives in volatile memory. Most users probably want to preserve files and settings across reboots, though. So this second part of the netboot series shows how to reconfigure the netboot image from part one so that Active Directory user accounts can log in and their home directories can be automatically mounted from a NFS server.

Part 3 of this series will show how to make an interactive and centrally-configurable iPXE boot menu for the netboot clients.

Setup NFS4 Home Directories with KRB5 Authentication

Follow the directions from the previous post “Share NFS Home Directories Securely with Kerberos,” then return here.

Remove the Liveuser Account

Remove the “liveuser” account created in part one of this series:

$ sudo -i # sed -i '/automaticlogin/Id' /fc28/etc/gdm/custom.conf # rm -f /fc28/etc/sudoers.d/liveuser # for i in passwd shadow group gshadow; do sed -i '/^liveuser:/d' /fc28/etc/$i; done

Configure NTP, KRB5 and SSSD

Next, we will need to duplicate the NTP, KRB5, and SSSD configuration that we set up on the server in the client image so that the same accounts will be available:

# MY_HOSTNAME=$(</etc/hostname) # MY_DOMAIN=${MY_HOSTNAME#*.} # dnf -y --installroot=/fc28 install ntp krb5-workstation sssd # cp /etc/ntp.conf /fc28/etc # chroot /fc28 systemctl enable ntpd.service # cp /etc/krb5.conf.d/${MY_DOMAIN%%.*} /fc28/etc/krb5.conf.d # cp /etc/sssd/sssd.conf /fc28/etc/sssd

Reconfigure sssd to provide authentication services, in addition to the identification service already configured:

# sed -i '/services =/s/$/, pam/' /fc28/etc/sssd/sssd.conf

Also, ensure none of the clients attempt to update the computer account password:

# sed -i '/id_provider/a \ \ ad_maximum_machine_account_password_age = 0' /fc28/etc/sssd/sssd.conf 

Also, copy the nfsnobody definitions:

# for i in passwd shadow group gshadow; do grep "^nfsnobody:" /etc/$i >> /fc28/etc/$i; done

Join Active Directory

Next, you’ll perform a chroot to join the client image to Active Directory. Begin by deleting any pre-existing computer account with the same name your netboot image will use:

# MY_USERNAME=jsmith # MY_CLIENT_HOSTNAME=$(</fc28/etc/hostname) # adcli delete-computer "${MY_CLIENT_HOSTNAME%%.*}" -U "$MY_USERNAME"

Also delete the krb5.keytab file from the netboot image if it exists:

# rm -f /fc28/etc/krb5.keytab

Perform a chroot into the netboot image:

# for i in dev dev/pts dev/shm proc sys run; do mount -o bind /$i /fc28/$i; done # chroot /fc28 /usr/bin/bash --login

Perform the join:

# MY_USERNAME=jsmith # MY_HOSTNAME=$(</etc/hostname) # MY_DOMAIN=${MY_HOSTNAME#*.} # MY_REALM=${MY_DOMAIN^^} # MY_OU="cn=computers,dc=${MY_DOMAIN//./,dc=}" # adcli join $MY_DOMAIN --login-user="$MY_USERNAME" --computer-name="${MY_HOSTNAME%%.*}" --host-fqdn="$MY_HOSTNAME" --user-principal="host/$MY_HOSTNAME@$MY_REALM" --domain-ou="$MY_OU"

Now log out of the chroot and clear the root user’s command history:

# logout # for i in run sys proc dev/shm dev/pts dev; do umount /fc28/$i; done # > /fc28/root/.bash_history

Install and Configure PAM Mount

We want our clients to automatically mount the user’s home directory when they log in. To accomplish this, we’ll use the “pam_mount” module. Install and configure pam_mount:

# dnf install -y --installroot=/fc28 pam_mount # cat << END > /fc28/etc/security/pam_mount.conf.xml <?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE pam_mount SYSTEM "pam_mount.conf.xml.dtd"> <pam_mount> <debug enable="0" /> <volume uid="1400000000-1499999999" fstype="nfs4" server="$MY_HOSTNAME" path="/home/%(USER)" mountpoint="/home/%(USER)" options="sec=krb5" /> <mkmountpoint enable="1" remove="0" /> <msg-authpw>Password:</msg-authpw> </pam_mount> END

Reconfigure PAM to use pam_mount:

# dnf install -y patch # cp -r /fc28/usr/share/authselect/default/sssd /fc28/etc/authselect/custom # echo 'initgroups: files' >> /fc28/etc/authselect/custom/sssd/nsswitch.conf # patch /fc28/etc/authselect/custom/sssd/system-auth << END @@ -12 +12,2 @@ -auth sufficient pam_sss.so forward_pass +auth requisite pam_mount.so {include if "with-pammount"} +auth sufficient pam_sss.so {if "with-pammount":use_first_pass|forward_pass} @@ -35,2 +36,3 @@ session required pam_unix.so +session optional pam_mount.so {include if "with-pammount"} session optional pam_sss.so END # patch /fc28/etc/authselect/custom/sssd/password-auth << END @@ -9 +9,2 @@ -auth sufficient pam_sss.so forward_pass +auth requisite pam_mount.so {include if "with-pammount"} +auth sufficient pam_sss.so {if "with-pammount":use_first_pass|forward_pass} @@ -32,2 +33,3 @@ session required pam_unix.so +session optional pam_mount.so {include if "with-pammount"} session optional pam_sss.so END # chroot /fc28 authselect select custom/sssd with-pammount --force

Also ensure the NFS server’s hostname is always resolvable from the client:

# MY_IP=$(host -t A $MY_HOSTNAME | awk '{print $4}') # echo "$MY_IP $MY_HOSTNAME ${MY_HOSTNAME%%.*}" >> /fc28/etc/hosts

Optionally, allow all users to run sudo:

# echo '%users ALL=(ALL) NOPASSWD: ALL' > /fc28/etc/sudoers.d/users

Convert the NFS Root to an iSCSI Backing-Store

Current versions of nfs-utils may have difficulty establishing a second connection from the client back to the NFS server for home directories when an nfsroot connection is already established. The client hangs when attempting to access the home directory. So, we will work around the problem by using a different protocol (iSCSI) for sharing our netboot image.

First chroot into the image to reconfigure its initramfs for booting from an iSCSI root:

# for i in dev dev/pts dev/shm proc sys run; do mount -o bind /$i /fc28/$i; done # chroot /fc28 /usr/bin/bash --login # dnf install -y iscsi-initiator-utils # sed -i 's/nfs/iscsi/' /etc/dracut.conf.d/netboot.conf # echo 'omit_drivers+=" qedi "' > /etc/dracut.conf.d/omit-qedi.conf # echo 'blacklist qedi' > /etc/modprobe.d/blacklist-qedi.conf # KERNEL=$(ls -c /lib/modules | head -n 1) # INITRD=$(find /boot -name 'init*' | grep -m 1 $KERNEL) # dracut -f $INITRD $KERNEL # logout # for i in run sys proc dev/shm dev/pts dev; do umount /fc28/$i; done # > /fc28/root/.bash_history

The qedi driver broke iscsi during testing, so it’s been disabled here.

Next, create a fc28.img sparse file. This file serves as the iSCSI target’s backing store:

# FC28_SIZE=$(du -ms /fc28 | cut -f 1) # dd if=/dev/zero of=/fc28.img bs=1MiB count=0 seek=$(($FC28_SIZE*2))

(If you have one available, a separate partition or disk drive can be used instead of creating a file.)

Next, format the image with a filesystem, mount it, and copy the netboot image into it:

# mkfs -t xfs -L NETROOT /fc28.img # TEMP_MNT=$(mktemp -d) # mount /fc28.img $TEMP_MNT # cp -a /fc28/* $TEMP_MNT # umount $TEMP_MNT

During testing using SquashFS, the client would occasionally stutter. It seems that SquashFS does not perform well when doing random I/O from a multiprocessor client. (See also The curious case of stalled squashfs reads.) If you want to improve throughput performance with filesystem compression, ZFS is probably a better option.

If you need extremely high throughput from the iSCSI server (say, for hundreds of clients), it might be possible to load balance a Ceph cluster. For more information, see Load Balancing Ceph Object Gateway Servers with HAProxy and Keepalived.

Install and Configure iSCSI

Install the scsi-target-utils package which will provide the iSCSI daemon for serving our image out to our clients:

# dnf install -y scsi-target-utils

Configure the iSCSI daemon to serve the fc28.img file:

# MY_REVERSE_HOSTNAME=$(echo $MY_HOSTNAME | tr '.' "\n" | tac | tr "\n" '.' | cut -b -${#MY_HOSTNAME}) # cat << END > /etc/tgt/conf.d/fc28.conf <target iqn.$MY_REVERSE_HOSTNAME:fc28> backing-store /fc28.img readonly 1 </target> END

The leading iqn. is expected by /usr/lib/dracut/modules.d/40network/net-lib.sh.

Add an exception to the firewall and enable and start the service:

# firewall-cmd --add-service=iscsi-target # firewall-cmd --runtime-to-permanent # systemctl enable tgtd.service # systemctl start tgtd.service

You should now be able to see the image being shared with the tgtadm command:

# tgtadm --mode target --op show

The above command should output something similar to the following:

Target 1: iqn.edu.example.server-01:fc28 System information: Driver: iscsi State: ready I_T nexus information: LUN information: LUN: 0 Type: controller SCSI ID: IET 00010000 SCSI SN: beaf10 Size: 0 MB, Block size: 1 Online: Yes Removable media: No Prevent removal: No Readonly: No SWP: No Thin-provisioning: No Backing store type: null Backing store path: None Backing store flags:   LUN: 1 Type: disk SCSI ID: IET 00010001 SCSI SN: beaf11 Size: 10488 MB, Block size: 512 Online: Yes Removable media: No Prevent removal: No Readonly: Yes SWP: No Thin-provisioning: No Backing store type: rdwr Backing store path: /fc28.img Backing store flags: Account information: ACL information: ALL

We can now remove the NFS share that we created in part one of this series:

# rm -f /etc/exports.d/fc28.exports # exportfs -rv # umount /export/fc28 # rmdir /export/fc28 # sed -i '/^\/fc28 /d' /etc/fstab

You can also delete the /fc28 filesystem, but you may want to keep it for performing future updates.

Update the ESP to use the iSCSI Kernel

Ipdate the ESP to contain the iSCSI-enabled initramfs:

$ rm -vf $HOME/esp/linux/*.fc28.* $ MY_KRNL=$(ls -c /fc28/lib/modules | head -n 1) $ cp $(find /fc28/lib/modules -maxdepth 2 -name 'vmlinuz' | grep -m 1 $MY_KRNL) $HOME/esp/linux/vmlinuz-$MY_KRNL $ cp $(find /fc28/boot -name 'init*' | grep -m 1 $MY_KRNL) $HOME/esp/linux/initramfs-$MY_KRNL.img 

Update the boot.cfg file to pass the new root and netroot parameters:

$ MY_NAME=server-01.example.edu $ MY_EMAN=$(echo $MY_NAME | tr '.' "\n" | tac | tr "\n" '.' | cut -b -${#MY_NAME}) $ MY_ADDR=$(host -t A $MY_NAME | awk '{print $4}') $ sed -i "s! root=[^ ]*! root=/dev/disk/by-path/ip-$MY_ADDR:3260-iscsi-iqn.$MY_EMAN:fc28-lun-1 netroot=iscsi:$MY_ADDR::::iqn.$MY_EMAN:fc28!" $HOME/esp/linux/boot.cfg

Now you just need to copy the updated files from your $HOME/esp/linux directory out to the ESPs of all your client systems. You should see results similar to what is shown in the below screenshot:

Upgrading the Image

First, make a copy of the current image:

# cp -a /fc28 /fc29

Chroot into the new copy of the image:

# for i in dev dev/pts dev/shm proc sys run; do mount -o bind /$i /fc29/$i; done # chroot /fc29 /usr/bin/bash --login

Allow updating the kernel:

# sed -i 's/^exclude=kernel-\*$/#exclude=kernel-*/' /etc/dnf/dnf.conf

Perform the upgrade:

# dnf distro-sync -y --releasever=29

Prevent the kernel from being updated:

# sed -i 's/^#exclude=kernel-\*$/exclude=kernel-*/' /etc/dnf/dnf.conf

The above command is optional, but saves you from having to copy a new kernel out to the clients if you add or update a few packages in the image at some future time.

Clean up dnf’s package cache:

# dnf clean all 

Exit the chroot and clear root’s command history:

# logout # for i in run sys proc dev/shm dev/pts dev; do umount /fc29/$i; done # > /fc29/root/.bash_history

Create the iSCSI image:

# FC29_SIZE=$(du -ms /fc29 | cut -f 1) # dd if=/dev/zero of=/fc29.img bs=1MiB count=0 seek=$(($FC29_SIZE*2)) # mkfs -t xfs -L NETROOT /fc29.img # TEMP_MNT=$(mktemp -d) # mount /fc29.img $TEMP_MNT # cp -a /fc29/* $TEMP_MNT # umount $TEMP_MNT

Define a new iSCSI target that points to our new image and export it:

# MY_HOSTNAME=$(</etc/hostname) # MY_REVERSE_HOSTNAME=$(echo $MY_HOSTNAME | tr '.' "\n" | tac | tr "\n" '.' | cut -b -${#MY_HOSTNAME}) # cat << END > /etc/tgt/conf.d/fc29.conf <target iqn.$MY_REVERSE_HOSTNAME:fc29> backing-store /fc29.img readonly 1 </target> END # tgt-admin --update ALL

Add the new kernel and initramfs to the ESP:

$ MY_KRNL=$(ls -c /fc29/lib/modules | head -n 1) $ cp $(find /fc29/lib/modules -maxdepth 2 -name 'vmlinuz' | grep -m 1 $MY_KRNL) $HOME/esp/linux/vmlinuz-$MY_KRNL $ cp $(find /fc29/boot -name 'init*' | grep -m 1 $MY_KRNL) $HOME/esp/linux/initramfs-$MY_KRNL.img

Update the boot.cfg in the ESP:

$ MY_DNS1=192.0.2.91 $ MY_DNS2=192.0.2.92 $ MY_NAME=server-01.example.edu $ MY_EMAN=$(echo $MY_NAME | tr '.' "\n" | tac | tr "\n" '.' | cut -b -${#MY_NAME}) $ MY_ADDR=$(host -t A $MY_NAME | awk '{print $4}') $ cat << END > $HOME/esp/linux/boot.cfg #!ipxe kernel --name kernel.efi \${prefix}/vmlinuz-$MY_KRNL initrd=initrd.img ro ip=dhcp rd.peerdns=0 nameserver=$MY_DNS1 nameserver=$MY_DNS2 root=/dev/disk/by-path/ip-$MY_ADDR:3260-iscsi-iqn.$MY_EMAN:fc29-lun-1 netroot=iscsi:$MY_ADDR::::iqn.$MY_EMAN:fc29 console=tty0 console=ttyS0,115200n8 audit=0 selinux=0 quiet initrd --name initrd.img \${prefix}/initramfs-$MY_KRNL.img boot || exit END

Finally, copy the files from your $HOME/esp/linux directory out to the ESPs of all your client systems and enjoy!

As much as we enjoy tearing open a cozy couple of socks or peeling back the paper on a snazzy blender (you shouldn’t have!), we’re of the firm belief that educators reign supreme when it comes to giving the perfect gift. For them, giving is an almost year-round thing, and the results are useful for the rest of your life. In our last episode of What’s New in EDU for 2018, we look back on a year’s worth of tools that supercharged learning and the amazing educators who brought it all to life for students around the world.

If that’s you: Thank you! Over the past year we’ve heard from thousands of teachers, districts, students – even parents – who are excited to step foot in today’s classroom and step up the possibilities available to their students in the future. With your feedback, we’ve been able to keep tailoring tools for educators want to boost and protect student voice, elevating it above the din of our demanding lives. We’ve seen that when students feel heard, feel seen, and feel acknowledged, their motivation to learn grows substantially.

Our passion for empowering all students went big this year, with our CEO Satya Nadella announcing our partnership with the Made by Dyslexia initiative. Together, we’ve rolled out new features to make learning more accessible for the 700 million students living with dyslexia.

Our Learning Tools also got major updates, like the Picture Dictionary, and continued to grow alongside the students who rely on them for reading every day.

We also saw another brilliant Hack the Classroom event, where changemakers in education and the passionate innovators in student-centered learning invented new ways to help students build future-ready skills and ignite their interest in STEM learning.

Computer science got a bit of a makeover in 2018 as well – as you’ll see in the video above, there’s a reason “the world doesn’t need any more computer scientists,” with educators expanding the subject to include all different kinds of creative projects, passions and people.

You might also remember catching #FlipgridFever this year. We were happy to announce that Flipgrid joined the Microsoft family, helping recast the role of video in the classroom, from a passive experience to a tool that empowers and amplifies every student’s voice. We also kicked off our You Can series of Tips (You Can catch up on all of them here).

And we can’t forget Minecraft: Education Edition’s year of cool coding updates: We announced the new Minecraft Hour of Code tutorial, Voyage Aquatic, where students use their creativity and problem solving skills to explore and build underwater worlds with code. We also expanded coding possibilities in Minecraft: Education Edition with the new Code Builder update. If you’re looking forward to having some time off during the holidays, you can download a free trial of Minecraft: Education Edition now and practice coding at home!

Finally, let’s squeeze in one more thank you to all you hard-working educators. You’re changing the world, inspiring us constantly and always pushing us to think of new ways to help you write those student success stories. From inclusivity to STEM, to the addition of new tools like Flipgrid into the Microsoft family, it was an amazing year.

We’re primed and ready for next year – and beyond!

Catch up on 2018:

Open source software isn’t just transforming technology infrastructure around the world, it is also creating profound opportunities for people with relevant skills. From Linux to OpenStack to Kubernetes, employers have called out significant skills gaps that make it hard for them to find people fluent with cutting-edge tools and platforms. The Linux Foundation not only offers self-paced training options for widely known tools and platforms, such as Linux and Git, but also offers options specifically targeting the rapidly growing cloud computing ecosystem. The latest offering in this area is Monitoring Systems and Services with Prometheus (LFS241).

Prometheus is an open source monitoring system and time series database that is especially well suited for monitoring dynamic cloud environments. It contains a powerful query language and data model in addition to integrated alerting and service discovery support. The new course is specifically designed for software engineers and systems administrators wanting to learn how to use Prometheus to gain better insights into their systems and services.

Why is monitoring so crucial for today’s cloud stacks and environments? Because the metrics these monitoring tools provide allow administrators to see and anticipate potential problems, keep performance tuned, and more. Monitoring tools like Prometheus can also generate automated alerts, helping administrators respond to issues in real time.

The Site Reliability Engineering book covering Google’s key site reliability tools notes: “The idea of treating time-series data as a data source for generating alerts is now accessible to everyone through open source tools like Prometheus.”

As is true for most monitoring tools, Prometheus provides detailed and rich dashboard views of system and platform performance. Prometheus is also 100 percent open source and community-driven. All components are available under the Apache 2 License on GitHub.

Announced in November, this training course includes 20 to 25 hours of course material covering many of the tool’s major features, best practices, and use cases. Students will be able to monitor their systems and services effectively with Prometheus upon completion on this course. This course covers the following topics:

• Prometheus architecture

• Setting up and using Prometheus

• Monitoring core system components and services

• Basic and advanced querying

• Creating dashboards

• Instrumenting services and writing third-party integrations

• Alerting

• Using Prometheus with Kubernetes

• Advanced operational aspects

Hands-on training makes a big difference, and this course contains 55 labs that can be completed locally on a VM or in the cloud. What do you need in terms of prerequisites? Participants should have basic experience with Linux/Unix system administration and common shell commands, as well as some development experience in Go and/or Python and working with Kubernetes.

“Adoption of the Prometheus monitoring system is growing rapidly, leading to demand for more talent qualified to work with this technology, which is why we decided now is the time to develop this course,” said Clyde Seepersad, General Manager, Training & Certification, The Linux Foundation. “With content developed by Cloud Native Computing Foundation (CNCF), which hosts Prometheus, and Julius Volz, one of the founders of the project, there is no better option than LFS241 for learning the ins and outs of this solution.”

Interested in finding out more about Monitoring Systems and Services with Prometheus (LFS241)? Information and enrollment options for this $199 course are found here.