2021-12-24 09:43:00
On the CompTIA A+ Discord we got into a little chat about apt package management. Someone really wanted a real-world example. Since "apt install wireshark" doesn't really tell them much, I typed up the following.
What we haven't been hitting on here and which might not come up in the objectives either is "why?". Why do we even need yum, apt, brew, choco, dnf and so on?
To answer that in as short a time as possible: installing software can be a tricky thing, because of "dependencies". Software needs more software, which needs more software, to run.
A piece of software is almost never stand-alone: it needs libraries, drivers, programming language interpreters, supporting tools and so on. And if you start working with Python, Java, NodeJS and so on, you will really get stuck in "dependency hell".
On Windows, standalone software installs often come as MSI or EXE installer. On Linux they come in the form of DPKG, RPM and other package formats. Now, if you want to run software that was installed via only such an installer, you'll quickly run into problems "Help! I'm missing X, Y and Z! You need to install those too!".
Package managers like Yum, APT, Homebrew, Chocolatey and so on help us with that. They will look at the list of dependencies that such an RPM / DPKG might have and make a grocery list. :) "You want this? Fine, then we'll also get X, Y and Z and get'm setup for you."
That's the "WHY?". It makes sudo apt install wireshark so nice, because it'll fetch ALL the extras Wireshark needs to run. For example.
Now Overwatch? That's gonna be interesting. Because where do all these packages come from? From "repositories", central databases of software packages. They are often run by the company making your chosen Linux, but there's also independent ones (like choco, brew and more). Plus, commercial vendors also often have their own repositories setup which you can subscribe to. This is how you would install Microsoft's Gitlab, for example.
Question is: do Blizzard have a repo to install Overwatch from? I don't know. :)
kilala.nl tags: teaching, work, linux,
View or add comments (curr. 0)
2021-10-10 17:23:00
Here's a list of practice resources I suggest to my Linux+ students, for Bash and Linux in general.
Special mention:
Complete newb level:
Early on, for beginners:
Advanced:
kilala.nl tags: work, linux, teaching,
View or add comments (curr. 1)
2014-07-29 21:32:00
Yes, this blog has been quiet for quite a while. In part this is because I've put most of my private stuff behind logins, but also because I've had my professional development on a backburner due to my book translation.
But now I've started studying for my RHCE certification. A year ago (has it been that long?!) I achieved my RHCSA, which I'll now follow up with the Engineer's degree. Red Hat will still offer the RHEL6 exams until the 19th of december, so I'd better get my ass in gear :)
View or add comments (curr. 0)
2014-07-29 21:27:00
Oh happy day! I've been using F.Lux on my Macs for years now and my eyes thank me for it. This great piece of software will automatically adjust the color temperature of your computer's screen, based on your location and light in your surroundings.
During the day your screen's white will be white, but in the evenings it'll slowly turn much more orange. During this change you won't even notice it's happening, but the end result is awesome. You'll still be seeing "white" but with much less eyestrain. Even better: supposedly the smaller amount of blue light will help in falling asleep later on.
Now that I've started studying for my RHCE exams, I'm working extensively on CentOS again. Hellooooo bright light!
But not anymore. Turns out that xflux is a thing! It's a Linux daemon that quite literally is F.Lux, for Linux. No more burnt out corneas!
View or add comments (curr. 0)
2013-10-01 09:00:00
I have moved the project files into GITHub, over here.
FoxT Server Control (aka BoKS) is a product that has grown organically over the past two decades. Since its initial inception in the late nineties it has come to support many different platforms, including a few Linux versions. These days, most Linuxen support something called SELinux: Security Enhance Linux. To quote Wikipedia:
"Security-Enhanced Linux (SELinux) is a Linux kernel security module that provides the mechanism for supporting access control security policies, including United States Department of Defense-style mandatory access controls (MAC). It is a set of kernel modifications and user-space tools that can be added to various Linux distributions. Its architecture strives to separate enforcement of security decisions from the security policy itself and streamlines the volume of software charged with security policy enforcement."
Basically, SELinux allows you to very strictly define which files and resources can be accessed under which conditions. It also has a reputation of growing very complicated, very fast. Luckily there are resources like Dan Walsh' excellent blog and the presentation "SELinux for mere mortals".
Because BoKS is a rather complex piece of software, which dozens of binaries and daemons all working together across many different resources, integrating BoKS into SELiinux is very difficult. Thus it hasn't been undertaken yet and thus BoKS will not only require itself to be run outside of SELinux' control, it actually wants to have the software fully disabled. So basically you're disabling one security product, so you can run another product that protects other parts of your network. Not so nice, no?
So I've decided to give it a shot! I'm making an SELinux ruleset that will allow the BoKS client software to operate fully, in order to protect a system alongside SELinux. BoKS replicas and master servers are even more complex, so hopefully those will follow later on.
I've already made good progress, but there's a lot of work remaining to be done. For now I'm working on a trial-and-error basis, adding rules as they are needed. I'm foregoing the use of sealert for now, as I didn't like the rules it was suggesting. Sure, my method is slower, but at least we'll keep things tidy :)
Over the past few weeks I've been steadily expanding the boks.te file (TE = Type Enforcement, the actual rules):
v0.32 = 466 lines
v0.34 = 423 lines
v0.47 = 631 lines
v0.52 = 661 lines
v0.60 = 722 lines
v0.65 = 900+ lines
Once I have a working version of the boks.te file for the BoKS client, I will post it here. Updates will also be posted on this page.
Update 01/10/2013:
Looks like I've got a nominally working version of the BoKS policy ready. The basic tests that I've been performing are working now, however, there's still plenty to do. For starters I'll try to get my hands on automated testing scripts, to run my test domain through its paces. BoKS needs to be triggered to just about every action it can, to ensure that the policy is complete.
Update 19/10/2013:
Now that I have an SELinux module that will allow BoKS to boot up and to run in a vanilla environment, I'm ready to show it to the world. Right now I've reached a point where I can no longer work on it by myself and I will need help. My dev and test environment is very limited, both in scale and capabilities and thus I can not test every single feature of BoKS with this module.
I have already submitted the current version of the module to FoxT, to see what they think. They are also working on a suite of test scripts and tools, that will allow one to automatically run BoKS through its paces which will speed up testing tremendously.
I would like to remind you that this SELinux module is an experiment and that it is made available as-is. It is absolutely not production-ready and should not be used to run BoKS systems in a live environment. While most of BoKS' basic functions have been tested and verified to work, there are still many features that I cannot test in my current dev environment. I am only running a vanilla BoKS domain. No LDAP servers, no Kerberos, no other fancy features.
Most of the rules in this file were built by using the various SELinux troubleshooting tools, determining what access needs to be opened up. I've done it all manually, to ensure that we're not opening up too much. So yeah: trial and error. Lots of it.
This code is made available under the Creative Commons - Attribution-ShareAlike license. See here for full details. You are free to Share (to copy, distribute and transmit the work), to Remix (to adapt the work) and to make commercial use of the work under the following conditions:
So. How to proceed?
I'd love to discuss the workings of the module with you and would also very much appreciate working together with some other people to improve on all of this.
Update 05/11/2014:
Henrik Skoog from Sweden contacted me to submit a bugfix. I'd forgotten to require one important thing in the boks.te file. That's been fixed. Thanks Henrik!
Update 11/11/2014:
I have moved the project files into GITHub, over here.
kilala.nl tags: work, sysadmin, boks, linux,
View or add comments (curr. 0)
2013-07-16 22:00:00
With Red Hat's default virtualization software KVM, it's possible to remotely manage the virtual machines running on a system. See here for some regular 'virt-ception'.
Out of the box, libvirt will NOT allow remote management of its VMs. If you would like to run a virt-manager connection through SSH, you will need to play around with Polkit-1. There is decent documentation available for the configuration of libvirt and Polkit-1, but I thought I'd provide the briefest of summaries.
Go into /etc/polkit-1/localauthority/50-local.d and create a file called (for example) 10.libvirt-remote.pkla. This file should contain the following entries:
[libvirt Remote Management Access]
Identity=unix-group:libvirt
Action=org.libvirt.unix.manage
ResultAny=yes
ResultInactive=yes
ResultActive=yes
This setup will allow anyone with (secondary) group "libvirt" to manage VMs remotely. That's a nice option to put into your standard build!
kilala.nl tags: sysadmin, work, linux,
View or add comments (curr. 0)
All content, with exception of "borrowed" blogpost images, or unless otherwise indicated, is copyright of Tess Sluijter. The character Kilala the cat-demon is copyright of Rumiko Takahashi and used here without permission.