<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Shell on nidomiro</title><link>https://nidomiro.de/tags/shell/</link><description>Recent content in Shell on nidomiro</description><generator>Hugo</generator><language>en</language><lastBuildDate>Fri, 14 Mar 2025 10:43:41 +0100</lastBuildDate><atom:link href="https://nidomiro.de/tags/shell/index.xml" rel="self" type="application/rss+xml"/><item><title>More secure deployments via ssh</title><link>https://nidomiro.de/code/more-secure-deployments-via-ssh/</link><pubDate>Fri, 21 Aug 2020 12:00:00 +0000</pubDate><guid>https://nidomiro.de/code/more-secure-deployments-via-ssh/</guid><description>&lt;p>If we deploy an application automatically we have to grant the CI
(Continuous Integration) access to the server. Common practice is to do
that via a GitLab Runner or an ssh account on the server.&lt;/p>
&lt;p>Personally I would not recommend using a GitLab Runner for deployments,
because you have to maintain it. Another potential issue is, that you
normally register runners for your whole GitLab instance or groups. That
results in a scenario in which everyone can use that runner and
accidentally (or not) destroy, for example, your production server. To
avoid that you have to register the GitLab Runner in the Project it
belongs to only. But even then your production server can be misused as
a build worker and therefore create performance issues.&lt;/p></description></item><item><title>Automatic VirtualBox module signing for UEFI</title><link>https://nidomiro.de/2018/04/automatic-virtualbox-module-signing-for-uefi/</link><pubDate>Tue, 17 Apr 2018 19:49:00 +0200</pubDate><guid>https://nidomiro.de/2018/04/automatic-virtualbox-module-signing-for-uefi/</guid><description>&lt;p>These steps are for all those people who hate to sign the Virtualbox
modules every time and don’t want to disable UEFI.&lt;/p></description></item></channel></rss>