<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Posts on Fischnets - Ben Fischer</title><link>https://fischnets.tech/posts/</link><description>Recent content in Posts on Fischnets - Ben Fischer</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sun, 12 Jan 2025 13:52:00 -0500</lastBuildDate><atom:link href="https://fischnets.tech/posts/index.xml" rel="self" type="application/rss+xml"/><item><title>Automated Baremetal Ubuntu</title><link>https://fischnets.tech/posts/2025-01-12-automated-baremetal-ubuntu/</link><pubDate>Sun, 12 Jan 2025 13:52:00 -0500</pubDate><guid>https://fischnets.tech/posts/2025-01-12-automated-baremetal-ubuntu/</guid><description>&lt;h2 id="intro"&gt;Intro&lt;/h2&gt;
&lt;p&gt;&lt;img src="https://fischnets.tech/img/autoinstall-directory.jpg" alt="AutoInstall Directory" title="A directory showing the contents of an AutoInstall Drive"&gt;&lt;/p&gt;
&lt;p&gt;A long awaited (for me anyway) follow up to &lt;a href="https://fischnets.tech/posts/2020-01-07-automating-esx-install/"&gt;&lt;code&gt;Automating ESX Install&lt;/code&gt;&lt;/a&gt;. It&amp;rsquo;s been top of mind ever since I finally setup automated installation of ESXi on baremetal to do a similiar thing with some FOSS alternative. I &lt;em&gt;think&lt;/em&gt; I&amp;rsquo;ve landed on using some form of &lt;a href="https://www.linux-kvm.org/page/Main_Page"&gt;KVM&lt;/a&gt; and &lt;a href="https://libvirt.org/"&gt;LibVirt&lt;/a&gt; up and running along with containers on these hosts. I &lt;em&gt;think&lt;/em&gt; I&amp;rsquo;m leaning towards LXD at the moment. It could change. ¯\&lt;em&gt;(ツ)&lt;/em&gt;/¯ Could I have gone the &lt;a href="https://www.proxmox.com/en/"&gt;Proxmox&lt;/a&gt; route and gotten things like virtual switches and what not handled much more easily? Sure. Where&amp;rsquo;s the fun in that though? I briefly evaluated going Debian, maybe Alpine or Rocky. Ultimately though, I settled into using Ubuntu. (Old habits die hard afterall.) I think I&amp;rsquo;ll continue to use the lighter images for my containers still. This is bound to be the first of several posts in a series related to getting a functional alternative for ESX for my purposes.&lt;/p&gt;</description></item><item><title>Turing Pi2 Update</title><link>https://fischnets.tech/posts/2024-12-27-turing-pi-update/</link><pubDate>Fri, 27 Dec 2024 12:38:00 -0500</pubDate><guid>https://fischnets.tech/posts/2024-12-27-turing-pi-update/</guid><description>&lt;h2 id="updates-already"&gt;Updates Already&lt;/h2&gt;
&lt;p&gt;I can&amp;rsquo;t decide if it&amp;rsquo;s an overwhelming schedule, procrastination, or just being too busy for my own good. But
either way, it&amp;rsquo;s been a hot minute since &lt;a href="https://fischnets.tech/posts/2024-03-18-turing-pi/"&gt;&lt;code&gt;Turing Pi2 Setup&lt;/code&gt;&lt;/a&gt; and I pretty quickly
regretted putting 22.04 on the nodes rather than waiting for 24.04.&lt;/p&gt;
&lt;p&gt;And of course, initial attempts showed that it required a wee bit more work than I found the energy to document
and follow through on since I was using external NVMe drives.&lt;/p&gt;</description></item><item><title>Turing Pi2 Setup</title><link>https://fischnets.tech/posts/2024-03-18-turing-pi/</link><pubDate>Mon, 18 Mar 2024 15:56:33 -0900</pubDate><guid>https://fischnets.tech/posts/2024-03-18-turing-pi/</guid><description>&lt;h2 id="intro"&gt;Intro&lt;/h2&gt;
&lt;p&gt;Yikes! Almsot two years since actually getting a post out here&amp;hellip; Well I&amp;rsquo;ve been busy to say the least. I&amp;rsquo;ve got a backlog that always seems to be growing with ideas. Really high on my list is continuing the automation on the automated VSphere provisioning. As well as getting the &lt;a href="https://www.linux-kvm.org/page/Main_Page"&gt;KVM&lt;/a&gt; and &lt;a href="https://libvirt.org/"&gt;LibVirt&lt;/a&gt; stuff going. Possibly diving back into &lt;a href="https://www.proxmox.com/en/"&gt;Proxmox&lt;/a&gt;. Maybe &lt;a href="https://xcp-ng.org/"&gt;XCP-ng&lt;/a&gt;. Heck, &lt;a href="https://www.microsoft.com/en-us/evalcenter/evaluate-hyper-v-server-2019"&gt;Hyper-V&lt;/a&gt; isn&amp;rsquo;t even off the table. Obviously the Broadcomm aquisition has made this a bit more of a priority. Though I did recently renew my &lt;a href="https://www.vmug.com/"&gt;VMUG&lt;/a&gt; subscription so I can keep going for a bit.&lt;/p&gt;</description></item><item><title>Publishing Npm to Azure Devops With Github</title><link>https://fischnets.tech/posts/2022-08-15-publishing-npm-to-azure-devops-with-github/</link><pubDate>Mon, 15 Aug 2022 18:39:35 -0400</pubDate><guid>https://fischnets.tech/posts/2022-08-15-publishing-npm-to-azure-devops-with-github/</guid><description>&lt;h2 id="why-is-this-so-difficult-again"&gt;Why is this so difficult again?&lt;/h2&gt;
&lt;p&gt;What should have been a fairly straightforward task, turned out to be anything but. The task? Test, build, and publish a JavaScript package using NPM to an Azure DevOps package artifact registry using a GitHub action. Sounds straightforward enough, right? There are plenty of &lt;a href="https://stackoverflow.com/questions/53099434/using-auth-tokens-in-npmrc/61666885#61666885"&gt;Stack Overflow Questions&lt;/a&gt; with answers close to this. All with some variation on how to handle the credentials and tokens too. None were quite right though. Other solutions included pulling in some random GitHub action task and passing the details into that. But who wants to keep an audit yet another dependency?&lt;/p&gt;</description></item><item><title>Mikrotik Api</title><link>https://fischnets.tech/posts/2022-02-18-mikrotik-api/</link><pubDate>Fri, 18 Feb 2022 22:23:07 -0500</pubDate><guid>https://fischnets.tech/posts/2022-02-18-mikrotik-api/</guid><description>&lt;h2 id="getting-started-with-the-routeros-api"&gt;Getting started with the RouterOS API&lt;/h2&gt;
&lt;p&gt;The traditional &lt;a href="https://wiki.mikrotik.com/wiki/Manual:API"&gt;api&lt;/a&gt; has been included for quite some time. Starting with 6.43 the login procedure has been a bit changed. To make things simple when using the python RouterOS-api package, plaintext_login = True is required. This makes the need for an SSL cert more important. To use the 7.1 &lt;a href="https://help.mikrotik.com/docs/display/ROS/REST&amp;#43;API"&gt;REST API&lt;/a&gt; An SSL cert is also required (it does not work over http)&lt;/p&gt;
&lt;h2 id="getting-a-cert"&gt;Getting a cert&lt;/h2&gt;
&lt;p&gt;We&amp;rsquo;re going to use a simple self signed cert for this example.
System -&amp;gt; Certificates: Add New.
The following should get set:
Name: &amp;ldquo;Self&amp;rdquo;
Country: &amp;ldquo;US&amp;rdquo;
State: &amp;ldquo;IN&amp;rdquo;
Locality: &amp;ldquo;Indianapolis&amp;rdquo;
Organization: &amp;ldquo;Contoso&amp;rdquo;
Unit: &amp;ldquo;IT&amp;rdquo;
Common Name: &amp;ldquo;router.contsoso.com&amp;rdquo;
Subject Alt. Name (SAN): IP; 192.0.2.1&lt;/p&gt;</description></item><item><title>Automating Provisioning</title><link>https://fischnets.tech/posts/2020-01-14-automated-prov/</link><pubDate>Tue, 14 Jan 2020 00:00:00 +0000</pubDate><guid>https://fischnets.tech/posts/2020-01-14-automated-prov/</guid><description>&lt;h3 id="updated-june-2022"&gt;Updated June 2022&lt;/h3&gt;
&lt;p&gt;The update included replacing the 18.04 image link with the 22.04LTS&lt;/p&gt;
&lt;h2 id="getting-started"&gt;Getting Started&lt;/h2&gt;
&lt;p&gt;This is the second in a series of posts about rapid standup of a lab environment. The first can be found &lt;a href="../2020-01-07-automating-esx-install/"&gt;here&lt;/a&gt;. This post will cover the basics of getting GOvmomi installed, linked, and usable for standing up an Ubuntu Cloud Image on a VCSA server. This can be modified to use on a local ESX host, and used for bootstrapping the VCSA.&lt;/p&gt;</description></item><item><title>Automating ESX Install</title><link>https://fischnets.tech/posts/2020-01-07-automating-esx-install/</link><pubDate>Tue, 07 Jan 2020 00:00:00 +0000</pubDate><guid>https://fischnets.tech/posts/2020-01-07-automating-esx-install/</guid><description>&lt;h2 id="automating-esxi-lab-rebuild"&gt;Automating ESXi Lab Rebuild&lt;/h2&gt;
&lt;p&gt;This is the first in a series of posts about rapid standup of the lab environment. Be it re-upping the trial period of ESXi, or just needing to blow everything away to get back to a fresh state after serious tinkering, being able to rapidly automate as much as possible is important to getting back to the fun of labbing. To help get this started, we&amp;rsquo;re going to leverage the ability to use the same USB drive as the install drive for ESX, and get basic information configured as well. This can also be extended to having a fleet of drives that can be stuck into servers for rapid pizza box standup.&lt;/p&gt;</description></item><item><title>Juniper SRX JunOS Upgrade</title><link>https://fischnets.tech/posts/2019-10-15-juniper-srx-junos-upgrade/</link><pubDate>Tue, 15 Oct 2019 00:00:00 +0000</pubDate><guid>https://fischnets.tech/posts/2019-10-15-juniper-srx-junos-upgrade/</guid><description>&lt;h2 id="juniper-junos-upgrade-instructions"&gt;Juniper JunOS Upgrade instructions&lt;/h2&gt;
&lt;p&gt;Tested/verified with SRX 340 and 345.&lt;/p&gt;
&lt;h2 id="getting-started"&gt;Getting Started&lt;/h2&gt;
&lt;p&gt;Begin by downloading the recommended version of JunOS per the following KB: &lt;a href="https://kb.juniper.net/InfoCenter/index?page=content&amp;amp;id=KB21476"&gt;https://kb.juniper.net/InfoCenter/index?page=content&amp;id=KB21476&lt;/a&gt;&lt;br&gt;
It seems to stay consistently up to date with JTAC recommended OS for the specific models.&lt;/p&gt;
&lt;p&gt;Once it&amp;rsquo;s downloaded, move it over to a FAT32 formatted drive. YMMV, but I used Windows 10 Format tool to format a 4GB flash drive to Fat32. Once the file (still zipped) is coppied over to the drive, plug it into the USB port. Alternatively, you can copy the image via SCP/SFTP/Carrier pidgeon to /var/tmp/IMAGE.tgz&lt;/p&gt;</description></item></channel></rss>