DevSensation

Disabling application in macOS

2026-03-16T21:04:00+01:00

Disabling application in macOS

In macOS systems I would like to totally disable some applications which have been in focus because of security flaws, such as FaceTime, Messages and Phone. Personally I do not use any of them, and that makes me think, why not reduce the attack surface by preventing them from being executed?

Searching information about .mobileconfig

It has been very tough to find information about .mobileconfig examples to disable those applications. Indeed I am surprised that AI could help me more than trying to find specific information, because it used to be the scenario where AI starts to hallucinate.

What I found

I found an example in an AI prompt which was showing the example below (it was extending even for Chess.app; which indeed is not used normally).

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt;
<plist version="1.0">
<dict>
    <key>PayloadIdentifier</key>
    <string>com.company.mcx.blockapps</string>
    <key>PayloadRemovalDisallowed</key>
    <true/>
    <key>PayloadScope</key>
    <string>System</string>
    <key>PayloadType</key>
    <string>Configuration</string>
    <key>PayloadUUID</key>
    <string>9c24d6b3-6233-4a08-a48d-9068f4f76cf0</string>
    <key>PayloadOrganization</key>
    <string>Company Name</string>
    <key>PayloadVersion</key>
    <integer>1</integer>
    <key>PayloadDisplayName</key>
    <string>Application Restrictions</string>
    <key>PayloadContent</key>
    <array>
        <dict>
            <key>PayloadType</key>
            <string>com.apple.applicationaccess.new</string>
            <key>PayloadVersion</key>
            <integer>1</integer>
            <key>PayloadIdentifier</key>
            <string>MCXToProfile.9c24d6b3-6233-4a08-a48d-9068f4f76cf0.alacarte.customsettings.2476221c-1870-4f3e-8c52-52386029c4cf</string>
            <key>PayloadEnabled</key>
            <true/>
            <key>PayloadUUID</key>
            <string>2476221c-1870-4f3e-8c52-52386029c4cf</string>
            <key>PayloadDisplayName</key>
            <string>Block Specified Applications From Launching</string>
            <key>familyControlsEnabled</key>
            <true/>
            <key>pathBlackList</key>
            <array>
                <string>/Applications/FaceTime.app/</string>
                <string>/Applications/Phone.app/</string>
                <string>/Applications/Messages.app/</string>
            </array>
            <key>pathWhiteList</key>
            <array>
                <string>/</string>
            </array>
            <key>whiteList</key>
            <array>
            </array>
        </dict>
    </array>
</dict>
</plist>

I tried a few examples before validating this one, and the result seems to be good. The important part is pathBlackList and pathWhiteList. On the first we specify the path to the applications we want to avoid executing; the second is a whitelist for well-known applications. I am against the second, because it is too broad, and I prefer the system, so in my personal .mobileconfig I have removed the pathWhiteList section.

BE AWARE that sometimes after applying the .mobileconfig and accepting the file had to be installed, I did not get the message forbidding the launch of the applications. After a reboot, the profile works as expected.

Wrap up!

We have seen an example of disabling macOS applications to reduce the attack surface on them, by using deny lists and allow lists.

Hope this helps! Cheers!

Customizing shell on macOS

2026-03-06T08:17:00+01:00

Customizing shell on macOS

I use to develop on Linux systems, but I do from a VM, and I was wondering how to customize in similar way for zsh in macOS. If you want to set up a shell environment similar to Linux using powerline, this article is for you.

The contents are the below:

Installing "0xProto nerd fonts mono".
Custom prompt by using starship.

Pre-requisites: brew is installed in your system

Installing "0xProto nerd fonts mono"

This font or another font for developing is necessary to print out properly the prompt. Below are the steps to install the font in the system.

# Download font
curl -L -O "https://github.com/ryanoasis/nerd-fonts/releases/download/v3.4.0/0xProto.zip"

# unpack the fonts at 0xProto/ directory
unzip 0xProto.zip -d 0xProto

# Install the fonts in the system
cp -vf 0xProto/*.ttf ~/Library/Fonts

# Reboot if you don't see the new fonts

Additionally I added the font to my VSCode IDE, so the embedded terminal experience is the same as my system terminal.

Open the VSCode settings.
Select User tab.
Search for 'Text Editor > Font : Font Family'
Add at the beginning: "0xProto Nerd Font Mono"

Custom prompt by using starship

Install starship by: brew install starship
Configure your starship by: starship preset gruvbox-rainbow -o ~/.config/starship.toml
Now we want to make effective the prompt configuration so we add the below to our .zshrc file or similar. In my case I have .profile.d/starship.zsh that is included from the .zshrc file:

sh if command -v starship &>/dev/null; then if tty -s &>/dev/null; then source <(starship init zsh) fi fi

Finally, close your terminal, and re-open again, and you will see your prompt shell customized.

Wrap up!

To have a prompt that display useful information for the developer is important to avoid human mistakes, and already is cool to have a prompt shell that display such information.

Hope this help!

See you on the next article!

Run windows powershell scripts

2026-02-13T10:00:00+01:00

Run windows powershell scripts

I have not used windows from a while, and several things that I use to do in Linux systems, are different in Windows. One of this things are customize my Windows terminal session by using an init script ($PROFILE) so I can define useful aliases (or functions in this case). But when I tried to use $PROFILE I realized that to allow it I had to degrade the ExecutionPolicy to be extremaly permissive, and setting the Scope to the Process, everytime I open a terminal, is tedious. So I have tried to sign my script so the ExecutionPolicy can be set to AllSigned and do not loose too much on the security levels. The steps could breakdown as below:

Define the initial content for the $PROFILE file.
Create a self-signed certificate.
Sign the $PROFILE file.
Verify we can run $PROFILE with no issues, and the function dotfiles is available.

Define the initial content

The initial $PROFILE content is only the below content (once it works we can add whatever we could need).

function dotfiles {
  git --git-dir="$HOME/.dotfiles/" --work-tree="$HOME" @args
}

Create a self-signed certificate

We have to create a self-signed certificate, store it in our local certificate storage (no system, so no privileges are needed).

$certName = "Alejandro Visiedo"
$dnsName = "PowerShellLocal"
$cert = New-SelfSignedCertificate -Type CodeSigningCert `
                                  -Subject "CN=$certName" `
                                  -DnsName $dnsName `
                                  -CertStoreLocation "Cert:\CurrentUser\My" `
                                  -NotAfter (Get-Date).AddYears(5) `
                                  -KeyExportPolicy NonExportable

-Type CodeSigningCert: We indicate we want a certificate to sign code as we want to sign our scripts.
-Subject "CN=$certName": We inform the value for the Subject of the certificate. As it is a self-signed, this value will be used to for the -Issuer.
-DnsName $dnsName: This value is not importante, just using a common value that is broadly used. It is important on the scope of TLS certificates.
-CertStoreLocation "Cert:\CurrentUser\My": Indicate the store where the certificates and key pair will be stored. As we are using the user store, we don't need elevate privileges.
-NotAfter (Get-Date).AddYears(5): The certificate will outdate in five years.
-KeyExportPolicy NonExportable: This argument indicate that the key stored are not exportable.

We can check the certificate by running certmgr.msc

And now configure the trust on the new certificate by:

$stores = "Root", "TrustedPublisher"
foreach ($storeName in $stores) {
    $store = New-Object System.Security.Cryptography.X509Certificates.X509Store($storeName, "CurrentUser")
    $store.Open("ReadWrite")
    $store.Add($cert)
    $store.Close()
    Write-Host "Added to: $storeName"
}

Sign the `$PROFILE` file

if (!(Test-Path $PROFILE)) { 
    New-Item -Path $PROFILE -Type File -Force 
    Add-Content $PROFILE "# File $PROFILE signed"
}

$status = Set-AuthenticodeSignature -FilePath $PROFILE -Certificate $cert
$status.Status

Verify

Get-AuthenticodeSignature $PROFILE | Select-Object Path, Status, Hash

Final script

Before to enable $PROFILE you have to run:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy AllSigned

As we can see, we shrink the scope to the current user only, and the execution policy will be applied to all signed scripts.

Any script from other user that we don't trust or not signed scripts will be rejected its execution.

Finally all the above together could be joined in the script below:

# 1. Configure names
$certName = "Alejandro Visiedo"
$dnsName = "PowerShellLocal"

Write-Host "--- Generating Certificate ---" -ForegroundColor Yellow
$cert = New-SelfSignedCertificate -Type CodeSigningCert `
                                  -Subject "CN=$certName" `
                                  -DnsName $dnsName `
                                  -CertStoreLocation "Cert:\CurrentUser\My" `
                                  -NotAfter (Get-Date).AddYears(5) `
                                  -KeyExportPolicy NonExportable

Write-Host "Certificate create with Thumbprint: $($cert.Thumbprint)"

# 2. Trust on the certificate (Move to root and trusted editors)
Write-Host "--- Configuring trust ---" -ForegroundColor Yellow
$stores = "Root", "TrustedPublisher"
foreach ($storeName in $stores) {
    $store = New-Object System.Security.Cryptography.X509Certificates.X509Store($storeName, "CurrentUser")
    $store.Open("ReadWrite")
    $store.Add($cert)
    $store.Close()
    Write-Host "Added to: $storeName"
}

# 3. Sign $PROFILE
Write-Host "--- Signing $PROFILE ---" -ForegroundColor Yellow
if (!(Test-Path $PROFILE)) { 
    New-Item -Path $PROFILE -Type File -Force 
    Add-Content $PROFILE "# File $PROFILE signed"
}

$status = Set-AuthenticodeSignature -FilePath $PROFILE -Certificate $cert
$status.Status

Write-Host "--- Verification ---" -ForegroundColor Yellow
Get-AuthenticodeSignature $PROFILE | Select-Object Path, Status, Hash

Signing another script

# the long hash is the fingerprint for the certificate
$cert = Get-Item -Path "Cert:\CurrentUser\My\ea9a1d609c091bb023c1ccd54261e4982d747047"
$status = Set-AuthenticodeSignature -FilePath "myscript.ps1" -Certificate $cert
$status.Status

Wrap up!

We have seen how to prepare our environment to run powershell scripts without relaxing the execution policy, and how to add a customization for our environment by defining the dotfiles function. Now we can extend this for additional helper scripts we could want to create in our environment.

What's the next? IMHO use a hardware key increase the security, so instead of having a certificate in the system certificate storage, I'd rather to have the private key stored in a cryptographic device (one ring to govern all the realms).

Another question is, how to rotate the certificate? What happen after 5 years?

But that will be another story.

See you on the next article!

Disable wsdd service

2025-11-23T13:11:00+01:00

Disable wsdd service

The Web Search Discovery host Daemon allow to discover hosts in a windows network. It uses ports 3702/udp and 5357/tcp. But this service reveals information that we could want to void, because it makes easier the discovery and recognition in a network.

This service is not managed by systemd, but exists a way to disable it, by using gsettings command.

So to disable the service run:

gsettings set org.gnome.system.wsdd display-mode 'disabled'

You could need to reboot, but after that, you should not see the service listening on port 3702/udp and 5357/tcp.

See you on the next post!

References

https://github.com/christgau/wsdd https://gitlab.gnome.org/GNOME/gvfs/-/issues/753

Passwordless environment

2025-10-31T01:00:00+01:00

Passwordless environment

The below are the steps I have followed to get passwordless on a Silverblue 43 distro with yubico. It is based in the steps found at the references.

I recommend to try in a VM before use in your primary system, and then extend to it.

Requirements

Install the required packages: rpm-ostree install pam-u2f pamu2fcfg
Reboot to get the packages available: systemctl reboot
Create directory where store the configuration for your account: mkdir ~/.config/Yubico
Add the configuration line by: pamu2fcfg --username=$USER >> ~/.config/Yubico/u2f_keys
Shrink permissions: chmod 0400 ~/.config/Yubico/u2f_keys
Copy u2f_keys to a the global location below by: cat ~/.config/Yubico/u2f_keys | run0 tee -a /etc/u2f_mappings

Set up passwordless

$ run0 authselect enable-feature with-pam-u2f

Set up 2FA

$ run0 authselect enable-feature with-pam-u2f-2fa

Notes about pamu2fcfg:

For the yubikey I am using, I required to use the --username=$USER argument or I got error: fido_dev_make_cred (63) FIDO_ERR_UV_INVALID

Setup Git signing

Generate the key pair as below:

ssh-keygen -t ed25519-sk \
    -O resident \
    -O application=ssh: \
    -O verify-required \
    -f ~/.ssh/id_ed25519_sk_rk

-O resident indicate to generate a resident key.
-O application=ssh: set the application namespace associated to the handler key. By default it is ssh:, and we need to prefix it always with ssh: if we want to generate a different key for different purposes.
-O verify-required indicates to verify (by PIN or biometrics) the user when the key is going to be used.

OR (if you are moving your keys to another machine)

# The below will extract the resident key to use the private key stored
# inside the crypto device (the private key never is disclosed from the
# device). The below will extract all the resident keys (if you had
# one tagged `ssh:` and another `ssh:fedora`, both redident keys would
# be extracted.
cd ~/.ssh
ssh-keygen -K

NOTE: In macOS requires to install ssh from homebrew, because the openssh installed by the system does not have support for secret keys (physical security key) nor resident key (stored in the device internal memory).

I moved the identities from one system to another without compromise them.

Configure Git for SSH Signing:

git config --global gpg.format ssh
git config --global user.signingkey "~/.ssh/id_ed25519_sk_rk.pub"
git config --global commit.gpgSign true
git config --global tag.forceSignAnnotated true

Configure SSH (the key to identify does not match the defaults that try SSH, so we need to let it know to SSH by adding the content below to .ssh/config:

IdentityFile ~/.ssh/id_ed25519_sk_rk

This was detected in macOS system when verifying the connection by ssh -T git@github.com

Create and configure the allowed signers file.

touch ~/.ssh/allowed_signers
EMAIL="$(git config --global user.email)"
PUB_KEY="$(cat ~/.ssh/id_ed25519_sk_rk.pub | awk '{ print $2 }')"
printf '%s namespaces="git" ssh-ed25519 %s Git signing key %s\n' "${EMAIL}" "${PUB_KEY}" "${EMAIL}" >> ~/.ssh/allowed_signers
unset PUB_KEY EMAIL

Tell git where to find the allowed signers:

git config --global gpg.ssh.allowedSignersFile "~/.ssh/allowed_signers"

Don't forget to add your public key to yout github, gitlab or another SCM where you push your commits.

Unlock LUKS using FIDO2

I tried in a VM several configurations, and the one that fit well in terms of security and usability was the below one:

run0 systemd-cryptenroll \
  --fido2-device=auto \
  --fido2-with-client-pin=no \
  --fido2-with-user-presence=yes \
  --fido2-with-user-verification=yes \
  /dev/sdXY

Edit /etc/crypttab and add to your LUKS device entry: - fido2-device=auto

Verify enrollment by: run0; cryptsetup luksDump /dev/sdXY

Reboot your system: systemctl reboot and now you should be prompted for touching your FIDO 2 device.

If you want to only unlock the disk by using your FIDO2 device you can remove the password slot with the following command:

WARNING: Before run this command, check you can boot and unlock LUKS by using your FIDO2 device.

run0 systemd-cryptenroll \
    --wipe-slot=password \
    /dev/sdXY

Update /dev/sdXY by your LUKS partition;lsblk` should help you.

Reboot your system: systemctl reboot and now you should be able to unlock your LUKS partition using your FIDO2 device and touching it.

Lock screen on extracting token

Create the file /usr/local/bin/lockcomputer.sh:

# Create /usr/local/bin/lockcomputer.sh
cat <<EOF | run0 tee /usr/local/bin/lockcomputer.sh
#!/bin/sh

# Inspired by: https://gist.github.com/jhass/070207e9d22b314d9992

# INFO This script lock the screen and disconnect network when it is invoked

lockscreen() {
  busctl call org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager LockSessions
}

disconnect-network() {
  devices=$(nmcli --fields DEVICE,TYPE,STATE device status | grep ethernet | grep connected | awk '{ print $1 }')
  for device in $devices; do
    nmcli device down "$device"
  done
}

main() {
  echo "lockcomputer.sh: $*" >> /tmp/lockcomputer.log
  disconnect-network
  lockscreen
}

main "$@"

EOF

# Change permissions
run0 chmod u+x /usr/local/bin/lockcomputer.sh

Create udev rule file to lock the computer on removing the key event. This rule is generic, and it likely works for any fido device.

cat <<EOF | run0 tee /etc/udev/rules.d/20-yubico.rules
ACTION=="remove", ENV{ID_FIDO_TOKEN}=="1", RUN+="/usr/local/bin/lockcomputer.sh"
EOF

Reload udev rules by: run0 udevadm control -R

Wrap up

So far we set up our login, gdm, git commits and tags, LUKS and lockcomputer on key extraction by using our passwordkey token. This is a step forward to keep your environment safer.

Stay tuned and see you on the next post!

UPDATE: Added Unlock LUKS using FIDO2 section.

UPDATE: Fix the lockcomputer.sh script and udev rules

References

Grow logical volume

2025-10-22T17:52:00+02:00

Grow logical volume

Sometimes I had been the scenario where I needed to extend the logical volume of my system such as:

A VM which required more space and after increase the available disk I had to extend the logical volume.
A raspy using not the usual distros.

The same steps worked for me in a fedora system. I won't extend and I will go straight to the point.

In this steps I am using /dev/sda3 update it for your scenario:

Increase the physical partition: fdisk /dev/sda3
Increase the physical volume: pvresize /dev/sda3
Increase logical volume: /dev/mapper/systemVG-LVRoot -L+100%FREE
Grow filesystem: xfs_growfs /dev/mapper/systemVG-LVRoot

Hope this helps you in similar scenario, take the above steps at your own risk and create a backup before run them if you are not sure what your are running. Be warned that something wrong could state in a broken system.

See you on the next post!

Running LLM locally

2025-08-20T14:22:00+02:00

Running LLM locally

IA is an amazing new field, but we have to take it carefully. And one of the things rolling my mind is about keep prompts privates, so I was wondering to run it locally, so it can help me even with no Internet connection.

In my opinion, IA works as an assistant, not as a new developer that make the work for us, but helps a lot to get things, even new ideas that we didn't consider; also it can provide wrong responses, so we need to review carefully the responses.

Trying ollama

I move from one system to another, I like to test things, and at the moment of trying this I was using an Asahi Linux with Arch Linux.

I installed ollama by: run0 pacman -Sy extra/ollama.
Start the systemd service by: run0 systemctl start ollama.service

And I searched for some model at: https://ollama.com/models

And I pulled a model from it: ollama pull deepseek-coder

I started the LLM by: ollama run deepseek-coder:33b

This github thread was helpful to avoid to download twice the model because at the beginning I started it only for my user by ollama serve &

Positive things:

I install the LLM by using the package manager.
I can start to use quickly just starting the service, pulling a model, and starting to use that model.

Negative things:

After checking some models, the ones that works better (it is not a statement that accomplish, as it depends the data used for the training) are the one which size is bigger, so it takes time to download them, and you require a lot of memory to run them.
For Asahi Linux, it was not accelerating the process by using the GPU, so I could see how my workstation was about to take off.

Trying ramalama

After try ollama, I was worried about get it working with GPU acceleration, and googling a little I found ramalama, which provide that GPU acceleration, and pack the model ready to use for it in a container. The idea is great, and we can use the same models we found at ollama web page.

Create a directory: mkdir ramalama; cd ramalama
Create a virtual environment: python3 -m venv .venv && source .venv/bin/activate
Install ramalama by: pip install ramalama
Download a model by: ramalama pull deepseek-coder:33b
Run the model by: ramalama run deepseek-coder:33b

Positive things:

All the workload is moved to the GPU.
It is easy to install and use models.

Negative things:

I dislike to install it by using pip; I rather to install it from official distro packages, but I didn't find it at Arch Linux for Asahi Linux.

Wrap up

My first contact for running local LLM has not been bad, and I think is a powerful tool for the day to day; both tools helps on quickly start using a LLM model. If you are using an Asahi Linux, then your bet for ramalama will be the right option, in terms of performance. I would like to have more hardware to test more different scenarios.

I like the idea that ramalama has containers per gpu/llm-model so you get something ready to use and optimized quickly. I like it is running isolated, even without network access, so all the information is processed locally (when running by ramalama.

So, if you have the resources, now you have the way to use your local assistant to help you into your day to day.

References

https://ollama.com/models
https://github.com/ollama/ollama
https://github.com/containers/ramalama

Using SSH through proxy

2025-06-11T10:39:00+02:00

Using SSH through proxy

If the system that you are using use a local proxy for the outgoing connections, your SSH connections will be rejected without any additional configuration.

In my case I would like to use github and gitlab upstreams through the SSH connection, so I can push my changes.

It could be more solutions, but the one indicated here require nc tool installed in your system, and some changes to ~/.ssh/config file.

Install nc in fedora by: run0 dnf install -y nc
Open ~/.ssh/config and add the configuration below:

Host github.com
    ProxyCommand  nc --proxy-type http --proxy <proxy-host-or-ip>:<proxy-port> %h %p

Host gitlab.com
    ProxyCommand  nc --proxy-type http --proxy <proxy-host-or-ip>:<proxy-port> %h %p

NOTE Change <proxy-host-or-ip> by the address of your proxy, and <proxy-port> by the port where your proxy is listening.

If the number of hosts is small, I recommend to keep the list specific so you can block any outgoing connection to other hosts you don't know that your system is connecting to.

Wrap up!

We have have seen how we can use nc to use proxy connections to our git repositories when we have network restrictions.

Happy coding! :)

proxy on rpm-ostree

2025-06-04T15:43:00+02:00

proxy on rpm-ostree

Hi there! if you are here, probably are facing similar situation than me today! I installed Fedora Silverblue in a fresh VM, and I use a proxy to reach out Internet, so how to make the things work in Silverblue? I am going to enumerate the failed intents, before the final solution.

Failed intents

The first thing I thought was, well just setup the http in the system and that will make everything. Yeah! I did it, and I rebooted even several times, but no connection was happening through the proxy. It makes things like curl works from my terminal, but for any reason, not for rpm-ostree.

Secondly, I thought "well, maybe I have to indicate that information into the repo files". So I edited every .repo file at /etc/yum.repos.d/*.repo and I realoaded rpm-ostree by

run0 systemctl daemon-reload; run0 systemctl restart rpm-ostreed.service

Even I tried to reboot, but still rpm-ostree was failing and the request didn't go through my proxy.

Later, I tried googling about it, and I found the below reference which was really helpful:

https://github.com/coreos/rpm-ostree/issues/762#issuecomment-434256478

I did the change by: run0 systemctl edit --full rpm-ostreed.service, and adding the change below:

[Service]
Environment="http_proxy=http://<ip-for-my-proxy>:<port>"

I run run0 systemctl daemon-reload; run0 systemctl restart rpm-ostreed.service, but surprise, still not working! And I rebooted and nothing changed.

Final change

Finally, I realized that I could require another environment variable, and that was the key in case for it, so I added HTTPS_PROXY and I run run0 systemctl daemon-reload; run0 systemctl restart rpm-ostreed.service and finally, it started to work.

Wrap up!

If you are using a proxy in your system, and you want to use Silverblue or other rpm-ostree based distribution, you will need to add manually the http_proxy and HTTPS_PROXY to the rpm-ostreed.service configuration.

run0 systemctl edit --full rpm-ostreed.service

Add the environment variables:

[Service]
Environment="http_proxy=http://<ip-for-my-proxy>:<port>"
Environment="HTTPS_PROXY=http://<ip-for-my-proxy>:<port>"

Reload the configuration and restart the service by:

run0 systemctl daemon-reload
run0 systemctl restart rpm-ostreed.service

And finally upgrade your system:

run0 rpm-ostree upgrade

Welcome

2025-03-28T12:24:00+01:00

Welcome

DevSensation is a space where I will publish all my nerd stuff.

Starting by creating a static site by using python3-pelican, and the sky is the limit.

Configuring OCP for user namespaces

2022-01-31T10:45:58+01:00

Preparing an OpenShift cluster for using user namespaces involves several steps and hands-over. To simplify the process we are using some configurations at freeipa-kustomize that make easier that task.

Pre-requisites:

A 4.9 or 4.10 OpenShift cluster.
You are logged in the cluster and you have cluster-admin privileges.

Out of scope: Build the runc and cri-o rpm packages.

Setting the configuration node

Clone freeipa-kustomize repository:

sh git clone https://github.com/freeipa/freeipa-kustomize.git

Retrieve the machine config pools by:

sh oc get mcp

Set the POOL environment variables with the names of the machine config pool that are going to be configured:

sh export POOL="worker"

if you want to specify more than one:

sh export POOL="worker master"

Install some custom RPMs by:

sh export RPM_PACKAGES="https://ftweedal.fedorapeople.org/runc-1.0.3-992.rhaos4.10.el8.x86_64.rpm https://ftweedal.fedorapeople.org/cri-o-1.23.0-990.rhaos4.10.git8c7713a.el8.x86_64.rpm"

The RPMs above are experimental and will become obsolete. This show how you can customize the ocp node environment easily by using this configuration. Keep in mind that if they become a lower version than the version that ships in the cluster release, the RPM package will not be installed. Credits and thanks to Fraser Tweedale.

Now we just run:

sh make -C config/static/nodes/userns configure kustomize build config/static/nodes/userns | oc create -f -

Finally await the node state is updated by:

sh oc wait mcp/worker --for condition=updated --timeout=-1s

It will take a few minutes (5-10minutes) as the configuration is applied node by node, evacuate the node, restart the node, and make it available. This process is repeated for all impacted nodes. Eventually all the nodes will get a Ready state and they could be used.

How is it structured?

The main overlay at config/static/nodes/userns is a composition of smaller ones, that are divided on:

config/static/nodes/cgroup-v2: Configure cgroup-v2 into the node, enabling to mount cgroup v2 filessytem into the node.
config/static/nodes/userns-subid: Configure the necessary subid for the user namespaces. Different files can be found at config/static/nodes/userns-subid/files to spicify the subuid and subgid information.
99-crio-userns.conf: Enable the io.kubernetes.cri-o.userns-mode annotation into the PodSpec.
subuid and subgid: Configure the subordinate ids to be used by the user namespace.
config/static/nodes/rpm-overrides: This configuration handle the RPM package installation. This is made by creating a systemd unit, and executing the command that install the RPM package. It is generated a resource for each RPM and POOL. The package installation is checked before launch the RPM command, so that future reboots does not try to install the RPM package again. Here this is used for custom runc and cri-o rpm packages, but this configuration could work for any RPM that we want to quickly test into our OCP development cluster.

Checking that the configuration was applied

Here you will find several commands that are executed from the node. If you are using CodeReadyContainers you can directly use a ssh command such as:

ssh -i ~/.crc/machines/crc/id_ecdsa core@192.168.130.11

This could be helpful when the KAS communication is not available.

Or you can just open a terminal into the node and run the command there by:

# Retrieve node list by:
oc get nodes
# Open the terminal by:
oc debug node/NODE
chroot /host
# Now run your commands here

For the RPM packages check from the node:

sh runc --version

raw runc version 1.0.3 spec: 1.0.2-dev go: go1.17.2 libseccomp: 2.5.1

sh # If you are using code ready containers, you can directly do the below ssh -i ~/.crc/machines/crc/id_ecdsa core@192.168.130.11 journalctl -u install-runc.service # Or using the oc adm command oc adm node-logs -u install-runc.service NODE

raw -- Logs begin at Sat 2021-12-11 13:38:56 UTC, end at Wed 2022-01-26 07:12:23 UTC. -- Jan 26 06:50:13 crc-hsl9k-master-0 bash[1658]: package runc-1.0.3-992.rhaos4.10.el8.x86_64 is not installed Jan 26 06:50:13 crc-hsl9k-master-0 systemd[1]: Started Install custom runc. Jan 26 06:50:14 crc-hsl9k-master-0 bash[1658]: Downloading 'https://ftweedal.fedorapeople.org/runc-1.0.3-992.rhaos4.10.el8.x86_64.rpm'... done! Jan 26 06:50:16 crc-hsl9k-master-0 bash[1658]: Checking out tree 26d80bc...done Jan 26 06:50:16 crc-hsl9k-master-0 bash[1658]: No enabled rpm-md repositories. Jan 26 06:50:16 crc-hsl9k-master-0 bash[1658]: Importing rpm-md...done Jan 26 06:50:16 crc-hsl9k-master-0 bash[1658]: Resolving dependencies...done Jan 26 06:50:16 crc-hsl9k-master-0 bash[1658]: Applying 1 override and 5 overlays Jan 26 06:50:16 crc-hsl9k-master-0 bash[1658]: Processing packages...done Jan 26 06:50:16 crc-hsl9k-master-0 bash[1658]: Running pre scripts...done Jan 26 06:50:16 crc-hsl9k-master-0 bash[1658]: Running post scripts...done Jan 26 06:50:17 crc-hsl9k-master-0 bash[1658]: Running posttrans scripts...done Jan 26 06:50:17 crc-hsl9k-master-0 bash[1658]: Writing rpmdb...done Jan 26 06:50:18 crc-hsl9k-master-0 bash[1658]: Writing OSTree commit...done Jan 26 06:50:19 crc-hsl9k-master-0 bash[1658]: Staging deployment...done Jan 26 06:50:20 crc-hsl9k-master-0 systemd[1]: Stopping Install custom runc... Jan 26 06:50:20 crc-hsl9k-master-0 systemd[1]: install-runc.service: Succeeded. Jan 26 06:50:20 crc-hsl9k-master-0 systemd[1]: Stopped Install custom runc. Jan 26 06:50:20 crc-hsl9k-master-0 systemd[1]: install-runc.service: Consumed 94ms CPU time -- Reboot -- Jan 26 06:51:10 crc-hsl9k-master-0 bash[1656]: runc-1.0.3-992.rhaos4.10.el8.x86_64 Jan 26 06:51:09 crc-hsl9k-master-0 systemd[1]: Started Install custom runc. Jan 26 06:51:09 crc-hsl9k-master-0 systemd[1]: install-runc.service: Succeeded. Jan 26 06:51:09 crc-hsl9k-master-0 systemd[1]: install-runc.service: Consumed 11ms CPU time

For the cgroup2, run the below from the node:

sh mount | grep cgroup2

raw cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,seclabel) cgroup on /var/lib/containers/storage/overlay/1ec73edf3e99a0772aaab2ba0f27110bb879a9fe86f607acc9de822489a4a9e1/merged/sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,seclabel)

For the kernelarguments, run the below from the node:

sh # check kernel args in the node boot cat /proc/cmdline

raw BOOT_IMAGE=(hd0,gpt3)/ostree/rhcos-36fd944867b0e491991a65f6f3b7209c937fe3bd7cdbd855c7c5d5a7070ce570/vmlinuz-4.18.0-305.28.1.el8_4.x86_64 random.trust_cpu=on console=tty0 console=ttyS0,115200n8 ignition.platform.id=qemu ostree=/ostree/boot.1/rhcos/36fd944867b0e491991a65f6f3b7209c937fe3bd7cdbd855c7c5d5a7070ce570/0 root=UUID=91ba4914-fd2b-4a7c-b498-28585a80a40e rw rootflags=prjquota systemd.unified_cgroup_hierarchy=1 cgroup_no_v1=all psi=1

For the subid configuration we run the below from the node:

sh cat /etc/subuid cat /etc/subgid

raw core:100000:65536 containers:200000:268435456

And we can observe that entries for container user and group exists too:

sh getent passwd containers getent group containers

raw containers:x:1001:995:User for housing the sub ID range for containers:/var/home/containers:/sbin/nologin

raw containers:x:995:

For the cri-o configuration we run the below from the node:

sh cat /etc/crio/crio.conf.d/99-crio-userns.conf

raw # https://github.com/cri-o/cri-o/blob/main/docs/crio.conf.5.md#crioruntimeruntimes-table [crio.runtime.runtimes.runc] allowed_annotations=["io.kubernetes.cri-o.userns-mode"]

Now we can use the annotation below to enable user namespaces for a particular Pod:

yaml apiVersion: v1 kind: Pod metadata: name: test-userns annotations: io.kubernetes.cri-o.userns-mode: "auto:size=65536" spec: serviceAccountName: test-userns containers: - name: userns-test image: quay.io/fedora/fedora:35 command: ["sleep", "3600"]

Let's try quickly with the below:

sh # Create a namespace oc new-project test-userns # Create the 'test-userns' service account to be used oc create sa test-userns # Add edit role to the sa oc adm policy add-role-to-user edit -z test-userns # Add anyuid security context constraint to the sa oc adm policy add-scc-to-user anyuid -z test-userns # We create the service oc create -f pod.yaml --as system:serviceaccount:$( oc project -q ):test-userns

When the pod is ready, we check the user namespace by:

sh oc exec pod/test-userns -- cat /proc/1/uid_map

raw 0 200000 65536

This means that the [0..65535] uids inside the container are mapped to [200000..265535] into the parent container.

When the user namespace is not used, the content of this file will be:

raw 0 0 4294967295

Wrap-up

With this configuration we can quickly set up our OCP cluster to quickly experiment with and investigate user namespace.

Knowledgements

Thanks to Fraser Tweedale for his sessions to understand better the user namespaces.

References

Stopping systemd workloads in OpenShift

2021-11-29T17:00:00+01:00

Are you using systemd workloads? Then this article could be of interest. In this article we are going to see how workloads based on systemd can be stopped gracefully on OpenShift.

We are going to do hands-on activities, using a simple systemd workload which runs an nginx service. We will see the differences between using the workload in Podman and using the workload in OpenShift. Finally we will see how to overcome the limitation in OpenShift by using container lifecycle hooks.

Prerequisites

Podman is installed in your environment.
OpenShift client is installed into your environment.
You have access to an OpenShift cluster.

You can install a single node OpenShift using kcli or Code Ready Containers.

Updates:

This is happening in OpenShift but it will be fixed in 4.10 (verified on OpenShift 4.10.0-ci-20220107).
Here is the change at cri-o that fix this situation: https://github.com/cri-o/cri-o/pull/5366

Defining the workload

We are going to use the following simple Dockerfile.stopsignal-systemd Dockerfile to build our workload.

FROM quay.io/fedora/fedora:35
RUN dnf -y install procps nginx \
    && dnf clean all \
    && systemctl enable nginx
EXPOSE 80
# https://docs.docker.com/engine/reference/builder/#stopsignal
# https://www.freedesktop.org/software/systemd/man/systemd.html#SIGRTMIN+3
STOPSIGNAL SIGRTMIN+3
ENTRYPOINT ["/sbin/init"]

The STOPSIGNAL instruction is not needed by podman as it detects that the signal to be sent by podman stop should be SIGRTMIN+3, because the container process is systemd.

Now we build:

export IMG="quay.io/avisied0/demos:stopsignal-systemd"
podman build -t "${IMG}" -f Dockerfile.stopsignal-systemd .

Runnning container with podman

Firstly, let's see what happens with the workload when running with podman or docker:

CONTAINER_ID=$( podman run -it -d "${IMG}" )
podman logs --follow "${CONTAINER_ID}" &
podman stop "${CONTAINER_ID}"

And we get a result like the below:

[  OK  ] Removed slice Slice /system/getty.
[  OK  ] Removed slice Slice /system/modprobe.
[  OK  ] Stopped target Graphical Interface.
[  OK  ] Stopped target Multi-User System.
[  OK  ] Stopped target Login Prompts.
[  OK  ] Stopped target Timer Units.
[  OK  ] Stopped dnf makecache --timer.
[  OK  ] Stopped Daily rotation of log files.
[  OK  ] Stopped Daily Cleanup of Temporary Directories.
.
.
.
[  OK  ] Stopped target Swaps.
[  OK  ] Reached target System Shutdown.
[  OK  ] Reached target Unmount All Filesystems.
[  OK  ] Reached target Late Shutdown Services.
         Starting System Halt...
Sending SIGTERM to remaining processes...
Sending SIGKILL to remaining processes...
All filesystems, swaps, loop devices, MD devices and DM devices detached.
Halting system.
Exiting container.

[1]+  Done                    podman logs --follow "${CONTAINER_ID}"

What about OpenShift?

Let's try now our workload on OpenShift; you will need an OpenShift cluster or a single node OpenShift (you can get one by using kcli or Code Ready Containers).

Push the image to your image registry:

sh # Previously IMG was defined as below: # export IMG="quay.io/avisied0/demos:stopsignal-systemd" podman push "${IMG}"

Ensure the repository is public so that the cluster can pull the image.

Access your cluster as a cluster admin and create a new project:

sh oc login -u kubeadmin https://api.crc.testing:6443 oc new-project stopsignal

Create a serviceaccount with the necessary permissions for creating and running the workload; this is, edit role and anyuid SecurityContextConstraint:

sh oc create serviceaccount runasanyuid oc adm policy add-scc-to-user anyuid -z runasanyuid --as system:admin oc adm policy add-role-to-user edit -z runasanyuid --as system:admin

Create the Pod from the following pod-stopsignal-systemd.yaml file:

yaml apiVersion: v1 kind: Pod metadata: name: stopsignal-systemd labels: app: nginx spec: serviceAccountName: runasanyuid automountServiceAccountToken: false containers: - name: nginx image: quay.io/avisied0/demos:stopsignal-systemd imagePullPolicy: Always command: ["/sbin/init"] tty: true privileged: false

Create the workload using the new serviceaccount:

sh oc create -f pod-stopsignal-systemd.yaml --as system:serviceaccount:stopsignal:runasanyuid oc get all

Print out and follow the logs in the background.

sh oc logs pod/stopsignal-systemd -f --as system:serviceaccount:stopsignal:runasanyuid &

Try to stop the workload.

sh oc delete -f pod-stopsignal-systemd.yaml --as system:serviceaccount:stopsignal:runasanyuid

We get something like the below in the log output, but systemd and the pod are still running:

pod "systemd-nginx" deleted
systemd-nginx login: systemd v249.7-2.fc35 running in system mode (+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)
Detected virtualization podman.
Detected architecture x86-64.

We can see that systemd does not begin the stop sequence as was the case with podman. This is because OpenShift did not translate the STOPSIGNAL instruction specified in the Dockerfile (this will be fixed at OpenShift 4.10). To work around this situation we will use container lifecycle hooks, to explicitly send SIGRTMIN+3 to PID 1 (systemd).

Trying more isolated

Let's see if this happens only for SIGRTMIN+3 or for any signal specified via the STOPSIGNAL instruction. To investigate that, we will use the following Dockerfile.stopsignal-demo Dockerfile:

FROM quay.io/fedora/fedora:35
COPY demo-signal.sh /demo-signal.sh
RUN chmod a+x /demo-signal.sh
STOPSIGNAL SIGINT
CMD ["/demo-signal.sh"]

The demo-signal.sh should have execute permission. The content is:

#!/bin/bash

function trap_signal {
  local signal="$1"
  echo -e "\nExiting by ${signal}" >&2
  exit 0
}

for signal in SIGINT SIGTERM SIGUSR1 "SIGRTMIN+3"
do
  trap "trap_signal '${signal}'" "${signal}"
done

while true; do
    echo -n "."
    sleep 1
done

Update: Script updated based on PR at: https://github.com/avisiedo/freeipa-kustomize/blob/idmocp-331-stopping-with-kind-and-podman/incubator/013-signalstop/demo-signal.sh

Finally we define a workload with the following pod-stopsignal-demo.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: stopsignal-demo
  labels:
    app: stopsignals
spec:
  automountServiceAccountToken: false
  containers:
  - name: main
    image: quay.io/avisied0/demos:stopsignal-demo
    imagePullPolicy: Always
    command:
    - /demo-signal.sh
    tty: true
    privileged: false

Build the image and push:

export IMG="quay.io/avisied0/demos:stopsignal-demo"
podman build -t "${IMG}" -f Dockerfile.stopsignal-demo .
podman push "${IMG}"

And we try the scenario by:

oc create -f pod-stopsignal-demo.yaml --as system:serviceaccount:stopsignal:runasanyuid
oc logs pod/stopsignal-demo -f --as system:serviceaccount:stopsignal:runasanyuid &
oc delete -f pod-stopsignal-demo.yaml --as system:serviceaccount:stopsignal:runasanyuid

Getting the output below:

pod "stopsignal-demo" deleted
............
Exiting by SIGINT

When the SIGINT is specified into the STOPSIGNAL instruction in the Dockerfile OpenShift is sending SIGINT signal to the pod when we delete the resource.

When the STOPSIGNAL 37 (RTMIN+3) is specified as a numeric value, OpenShift is sending SIGTERM instead of the expected SIGRTMIN+3 indicated into the Dockerfile file.

Update:

Another test was made in OpenShift 4.10 ci build on Wed Jan 5, 2022 and it worked as expected, by sending the SIGRTMIN+3 to the container workload. So this will be fixed in future releases.

Solution: container lifecycle hooks

Create pod-stopsignal-lifecycle.yaml with the content below:

yaml apiVersion: v1 kind: Pod metadata: name: stopsignal-lifecycle labels: app: nginx spec: serviceAccount: runasanyuid containers: - name: nginx image: quay.io/avisied0/demos:stopping-systemd imagePullPolicy: Always command: ["/sbin/init"] tty: true privileged: false lifecycle: # (1) preStop: # (2) exec: # (3) command: ["kill", "-RTMIN+3", "1"] # (4)

(1) The lifecycle hooks for that container.
(2) A preStop hook is called before stopping the container.
(3) It will be an exec command.
(4) The command to be executed; the executable must exist in the container.
And we try again by:

sh oc create -f pod-stopsignal-lifecycle.yaml --as=system:serviceaccount:stopsignal:runasanyuid oc logs pod/stopsignal-lifecycle -f --as=system:serviceaccount:stopsignal:runasanyuid & oc delete -f pod-stopsignal-lifecycle.yaml --as=system:serviceaccount:stopsignal:runasanyuid

And the log output immediately shows the below:

pod "systemd-nginx" deleted
systemd-nginx login: [  OK  ] Removed slice Slice /system/getty.
[  OK  ] Removed slice Slice /system/modprobe.
[  OK  ] Stopped target Graphical Interface.
[  OK  ] Stopped target Multi-User System.
[  OK  ] Stopped target Login Prompts.
[  OK  ] Stopped target Timer Units.
[  OK  ] Stopped dnf makecache --timer.
[  OK  ] Stopped Daily rotation of log files.
[  OK  ] Stopped Daily Cleanup of Temporary Directories.
[  OK  ] Closed Process Core Dump Socket.
         Stopping Console Getty...
         Stopping The nginx HTTP and reverse proxy server...
         Stopping User Login Management...
[  OK  ] Stopped Console Getty.
         Stopping Permit User Sessions...
[  OK  ] Stopped User Login Management.
[  OK  ] Stopped Permit User Sessions.
systemd v249.7-2.fc35 running in system mode (+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)
Detected virtualization podman.
Detected architecture x86-64.
[  OK  ] Stopped The nginx HTTP and reverse proxy server.
[  OK  ] Stopped target Network is Online.
[  OK  ] Stopped target Host and Network Name Lookups.
[  OK  ] Stopped target Remote File Systems.
         Stopping Home Area Activation...
         Stopping Network Name Resolution...
[  OK  ] Stopped Network Name Resolution.
[  OK  ] Stopped Home Area Activation.
         Stopping Home Area Manager...
[  OK  ] Stopped Home Area Manager.
[  OK  ] Stopped target Basic System.
[  OK  ] Stopped target Path Units.
[  OK  ] Stopped Dispatch Password …ts to Console Directory Watch.
[  OK  ] Stopped Forward Password R…uests to Wall Directory Watch.
[  OK  ] Stopped target Slice Units.
[  OK  ] Removed slice User and Session Slice.
[  OK  ] Stopped target Socket Units.
         Stopping D-Bus System Message Bus...
[  OK  ] Stopped D-Bus System Message Bus.
[  OK  ] Closed D-Bus System Message Bus Socket.
[  OK  ] Stopped target System Initialization.
[  OK  ] Stopped target Local Verity Protected Volumes.
[  OK  ] Stopped Update is Completed.
[  OK  ] Stopped Rebuild Dynamic Linker Cache.
[  OK  ] Stopped Rebuild Journal Catalog.
         Stopping Record System Boot/Shutdown in UTMP...
[  OK  ] Stopped Record System Boot/Shutdown in UTMP.
[  OK  ] Stopped Create Volatile Files and Directories.
[  OK  ] Stopped target Local File Systems.
         Unmounting /etc/hostname...
         Unmounting /etc/hosts...
         Unmounting /etc/resolv.conf...
         Unmounting /run/lock...
         Unmounting /run/secrets/kubernetes.io/serviceaccount...
         Unmounting Temporary Directory /tmp...
         Unmounting /var/log/journal...
[  OK  ] Stopped Create System Users.
[FAILED] Failed unmounting /etc/hosts.
[FAILED] Failed unmounting /run/lock.
[FAILED] Failed unmounting /run/sec…/kubernetes.io/serviceaccount.
         Unmounting /run/secrets...
[FAILED] Failed unmounting /etc/resolv.conf.
[FAILED] Failed unmounting Temporary Directory /tmp.
[FAILED] Failed unmounting /var/log/journal.
[FAILED] Failed unmounting /etc/hostname.
[FAILED] Failed unmounting /run/secrets.
[  OK  ] Stopped target Swaps.
[  OK  ] Reached target System Shutdown.
[  OK  ] Reached target Unmount All Filesystems.
[  OK  ] Reached target Late Shutdown Services.
         Starting System Halt...
Sending SIGTERM to remaining processes...
Sending SIGKILL to remaining processes...
All filesystems, swaps, loop devices, MD devices and DM devices detached.
Halting system.
Exiting container.

Wrap up

In this article we have seen that:

systemd workloads need SIGRTMIN+3 for stopping the workload gracefully.
OpenShift does not send the signal specified in the container image (via the STOPSIGNAL instruction). It does starting in OpenShift 4.10.
We can use a container lifecycle hook to interact with the workload when stopping the container until the fix is available. For this scenario, we can use the kill binary (which must exist in the container) to send SIGRTMIN+3 to PID 1 (systemd).

Updates:

The reason the STOPSINAL instruction is not interpreted in OpenShift is because the signal name RTMIN+3 is not properly parsed. Actually there are a fix for this situation (this PR), that has been seen that will be included in OpenShift 4.10. Until this version is released, the solution above could make the works.

References

How to run systemd in a container.
Systemd SIGRTMIN+3.
Dockerfile - STOPSIGNAL.
Container Lifecycle Hooks.
Attach Handlers to Container Lifecycle Events.
UPDATE: BZ 2000877.

DevSensation

Disabling application in macOS

Disabling application in macOS

Searching information about .mobileconfig

What I found

Wrap up!

Customizing shell on macOS

Customizing shell on macOS

Installing "0xProto nerd fonts mono"

Custom prompt by using starship

Wrap up!

Run windows powershell scripts

Run windows powershell scripts

Define the initial content

Create a self-signed certificate

Sign the $PROFILE file

Verify

Final script

Signing another script

Wrap up!

Disable wsdd service

Disable wsdd service

References

Passwordless environment

Passwordless environment

Requirements

Set up passwordless

Set up 2FA

Setup Git signing

Unlock LUKS using FIDO2

Lock screen on extracting token

Wrap up

References

Grow logical volume

Grow logical volume

Running LLM locally

Running LLM locally

Trying ollama

Trying ramalama

Wrap up

References

Using SSH through proxy

Using SSH through proxy

Wrap up!

proxy on rpm-ostree

proxy on rpm-ostree

Failed intents

Final change

Wrap up!

Welcome

Welcome

Configuring OCP for user namespaces

Setting the configuration node

How is it structured?

Checking that the configuration was applied

Wrap-up

Knowledgements

References

Stopping systemd workloads in OpenShift

Defining the workload

Runnning container with podman

What about OpenShift?

Trying more isolated

Solution: container lifecycle hooks

Wrap up

References

Sign the `$PROFILE` file