Ubuntu on blog.iankulin.com

Ubuntu Ansible 'waiting for privilege escalation prompt'

Sat, 16 May 2026 00:00:00 +0000

I ran into a hiccup today - provisioning a new Ubuntu VPS, the ansible playbook to apply our security hardening failed.

 ~/Developer/ansible_hl % ansible-playbook ssh-harden.yml --ask-vault-pass -e @vault.yml 
Vault password: 

PLAY [Copy the hardened SSHD_CONFIG file to the remote server] ****************************************************

TASK [Gathering Facts] ********************************************************************************************
[ERROR]: Task failed: Timeout (12s) waiting for privilege escalation prompt:
fatal: [<redacted IP>]: UNREACHABLE! => {"changed": false, "msg": "Task failed: Timeout (12s) waiting for privilege escalation prompt:", "unreachable": true}

My routine is to run Ubuntu LTS, and when I was provisioning the server, I selected Ubuntu 26.04 LTS x64 without thinking. This LTS dropped in April, and excitingly the new versions of Ubuntu have Rust coreutils including sudo.

The cause of the issue above (where anisible waits for the sudo password request but never sees it) is that the password prompt in sudo-rs is different from real sudo. Here’s the old one:

ian@iris-orca:~$ sudo lsb_release -d
[sudo] password for ian: 
No LSB modules are available.
Description:	Ubuntu 24.04.4 LTS
ian@iris-orca:~$ sudo --version
Sudo version 1.9.15p5
Sudoers policy plugin version 1.9.15p5
Sudoers file grammar version 50
Sudoers I/O plugin version 1.9.15p5
Sudoers audit plugin version 1.9.15p5
ian@iris-orca:~$

And the new one:

ian@ksd-on-syd-001:~$ sudo lsb_release -d
[sudo: authenticate] Password: 
Description:	Ubuntu 26.04 LTS
ian@ksd-on-syd-001:~$ sudo --version
sudo-rs 0.2.13-0ubuntu1
ian@ksd-on-syd-001:~$

So, [sudo] password for ian: vs [sudo: authenticate] Password: .

It’s not a big deal, and ansible has already made a fix for the incompatibility, it just hasn’t flowed down to me yet. Ubuntu 24 is still LTS so I’ll drop back to that.

For the adventurous, another possible approach would be to create an ansible user with passwordless ssh - I’d rather wait for the ansible update before I move to a Linux version using sudo_rs.

apt update - BADSIG 871920D1991BC93C

Mon, 30 Oct 2023 00:00:00 +0000

I have an ansible script that runs each weekend which basically does an apt update && apt upgrade -Y on every Debian based instance. This weekend it failed on one Ubuntu host. When I went it to try it manually, this was the output:

Hit:1 http://au.archive.ubuntu.com/ubuntu jammy InRelease
Hit:2 https://download.docker.com/linux/ubuntu jammy InRelease 
Hit:3 http://au.archive.ubuntu.com/ubuntu jammy-backports InRelease 
Hit:4 http://au.archive.ubuntu.com/ubuntu jammy-security InRelease 
Get:5 http://au.archive.ubuntu.com/ubuntu jammy-updates InRelease [119 kB] 
Err:5 http://au.archive.ubuntu.com/ubuntu jammy-updates InRelease 
 The following signatures were invalid: BADSIG 871920D1991BC93C Ubuntu Archive Automatic Signing Key (2018) <ftpmaster@ubuntu.com>
Get:6 https://pkgs.tailscale.com/stable/ubuntu jammy InRelease
Fetched 125 kB in 1s (125 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
11 packages can be upgraded. Run 'apt list --upgradable' to see them.
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://au.archive.ubuntu.com/ubuntu jammy-updates InRelease: The following signatures were invalid: BADSIG 871920D1991BC93C Ubuntu Archive Automatic Signing Key (2018) <ftpmaster@ubuntu.com>
W: Failed to fetch http://au.archive.ubuntu.com/ubuntu/dists/jammy-updates/InRelease The following signatures were invalid: BADSIG 871920D1991BC93C Ubuntu Archive Automatic Signing Key (2018) <ftpmaster@ubuntu.com>
W: Some index files failed to download. They have been ignored, or old ones used instead.

Solved

The first google result mentions apt-cache - which I also run, so a first level debug step is to delete the /etc/apt/apt.conf.d/00aptproxy file that redirects apt requests to the cache I run in an LXC container. After that, if I re-run the apt update it works perfectly. Seems like a problem with the cache then. I’m not sure why it would only affect this host though - I have other Ubuntu VM’s in the fleet that are not getting the original error.

In any case, adding the conf back to force the server to use the cache made the error reappear - so it’s definitely related to the cache. With any type of cache, when there’s a problem related to it, deleting the contents is usually a “plan A” response. Assuming there’s some mechanism in Apt Cacher NG to do this, I went to the little stats/config webpage it serves up.

Well “Force the download of index files” sounds promising, let’s try that.

I ticked the box for Force the download of index files (even having fresh ones), but it wasn’t clear to me how to make that change stick. The first button I could click further down the page was “Start Scan” which was related to some different checkboxes. I tried it anyway, but it didn’t force the downloading of index files. Time for some command line comandoing.

The cache files for aptcacher-ng are in /var/cache/apt-cacher-ng/ each distro has a directory in there.

Guessing the Ubuntu repository cache is probably stored in uburep, I deleted that with rm -R /var/cache/apt-cacher-ng/uburep. When I retried the apt update, it worked perfectly, and I could see that the /var/cache/apt-cacher-ng/uburep directory had re-appeared.

That’s the immediate problem fixed. The cause of this problem is unclear. Presumably it related to a package running on this Ubuntu machine (runs docker with a couple of small services) that is not running on my other Ubuntu hosts. It probably falls into the category of “don’t worry about unless it crops up again”.

How to deploy a Node.js app

Wed, 05 Jul 2023 00:00:00 +0000

This is one of those things that is simple once you know it. I had my tiny Node service working on my MacBook, but how do I run it on the server?

Native or Container

Obviously I need Node.js installed on the server, should I have it in a Docker container, or native on the machine. There’s no clear answer here - in a container set up with Docker Compose might be more in line with my ideology of treating machines as disposable, but a native install is simpler, and I probably want to make life simpler at this stage when I’m learning everything.

Installing Node

This took me down a bigger rabbit hole than I was expecting. My VPS is Unbuntu LTS 22.04.2, so I spun one of those up in a VM on the homelab to try things out.

A quick google search suggested the NodeSource binary distributions. That involves curling a big script (when I pasted the script into ChatGPT it said it wasn’t malicious). I could chose the Node version, so I grabbed 20.x That was as painless as you’d expect.

Then I started wondering why I couldn’t just apt install it. If I could do that, it would reduce the chance of a supply chain attack since I’d have the power of Canonical on my side. So I rolled the previous install back (thank you Proxmox backups of VMs), and tried:

apt install nodejs

That worked fine - Node is in the Ubuntu packages, but the version is quite old - v12.22.9. This is on the current Ubuntu LTS 22.04.2. I don’t think it will matter for my purposes, but it explains why you’d do something other than just this.

I’m also going to need npm, so lets get that with:

apt install npm

That seemed to download a heap more stuff that the node install.

Deploying your project

Again, the first search result was more complicated than I needed. The advice was to clone my repository onto the server where I wanted to deploy. This is such a minor project, I hadn’t pushed it up to GitHub. So that seemed excessive. You know, not everything has to be DevOps CI/CD! I mean, we ain’t talking about a very complicated project here:

I’ve got this tiny source file, and the text file I want to serve. All the dependencies (just Express) are in the package.json, so presumably that’s all I need on the server to get going.

I scp’d those from my laptop to a directory on the folder:

Once they are there, I need to install the packages from the package.json, so we do that with:

npm install

That installed 59 packages (presumably Express plus 58 of it’s dependencies). Then I started the app with:

node .

and it worked!

Insomnia

I should probably explain what you’re looking at above. I could have tested this little node server by going to the api address in a browser and checked that I got back the text file I was expecting. And in Chrome (and I assume Firefox) there are developer tools that would show the return code etc. However, most of the REST API videos I’ve watched use a better tool - mostly Postman. These sort of tools give you a heap of other capabilities, none of which I really need for this simple project, but will be very handy for more complex APIs where there is a body to the request.

The only reason I’m using Insomnia instead of Postman is that when I tried Postman, it straightaway wanted some of my data to make it work. Insomnia hasn’t forced me to do that yet.

Proxmox - Installing a Virtual Machine

Tue, 07 Feb 2023 00:00:00 +0000

Installing your first virtual machine (VM) in the Proxmox hypervisor is pretty straightforward. This post runs through those steps using Proxmox 7.3.

You need an operating system for your virtual machine, I’m going to use Ubuntu server in this example, but it could just as easily be Windows server, or regular windows, or one of the desktop Linux distributions. Whichever you decide, you’ll need to find and download the ISO for it. The ISO is a (usually quite large) file needed to install the operating system.

Once, you’ve got the ISO for the operating system, you need to upload it into Proxmox via the web interface. The ISO will be stored in the local directory style storage. If you click on it in Proxmox, you’ll see there’s actually a section for ISOs, as well as buttons there to upload an ISO from your machine, or to directly download it into ProxMox from a link.

Above you can seen I’ve now got two ISO images stored in my local storage. Once an image is there, you are ready to install it.

In the top right of the Proxmox screen there are two blue buttons. One of them says “Create VM”, and that’s what we want to do. Now there will be a series of dialogs to click through and fill out. Most things we can just leave as defaults, but a few need some decisions.

The node (your server) is already filled out. Mine is pve since I just used the default name when I first installed Proxmox. The VM (virtual machine) ID is used by Proxmox to identify the server. You can change this to any three digit number you haven’t used. I’m keeping 100. Some people use this to separate their server types, for example all their production servers might be in the three hundreds.

You need to come up with a name for this VM. These can only use letters and numbers - no punctuation. I like to keep them short, and describe the purpose of this VM, but perhaps you want to name yours after the OS you are using. I’m calling this one dockerhost because it’s going to host my Docker containers. Once you’ve decided, hit next.

Here’s where we choose the image, I’m going with the Unbuntu I downloaded earlier.

The System page - I’m just leaving all the defaults and hitting next.

On the Disks page, we go have a decision to make: how much drive space does this VM get. You’ll remember from our discussion about thin provisioning that we can allocate more disk than we have, but it’s not a good idea. The final decision about this is something you need to make considering the purpose of this VM and the space you’ve got available to you. You might need to google around for recommendations. It’s pretty easy to increase the disk size after your VM is created, but more difficult to reduce it.

The Wizard has suggested 32GB for me, but the minimum spec is for 2.5GB. I am going to be downloading a few large containers, so 10GB seems like a good starting point for me.

Next is the CPU’s. Leave the defaults for everything, except you need to make a decision about the number of cores. My baby server only has two cores, but yours may have a eight or more. Proxmox will ration things out to some extent by time slicing - so you can easily run eight VM’s all allocated one core on a four core processor. And in fact, since a lot of them will probably just be sitting there waiting for something to happen, none of them will need to wait.

It’s probably a bad idea to allocate all of your cores to one VM, so I’m going to say ‘one’ for mine, but you should also consider the processing needs of your VMs.

Another important consideration is the amount of memory. Again, the needs will be determined by your use case. In my case, the minimum spec is for 1GB, but I’m planning on loading up some large containers and I have 8GB in hardware. So I’ll go with 4GB. The story with the minimum memory field is a little bit complicated, but basically, setting this lower than the max memory gives Proxmox a little bit of flexibility to share it around if you’re not using it all - which sounds like a good idea, so I’ll say my minimum is 2GB.

Networking in a visualized environment is a whole thing. But I have simple needs and only one hardware port, so all these defaults are fine for us.

The Confirm page is just a last chance to look over what we’ve chosen, then we can press Finish to create our VM! A few seconds later it should be showing up in the server view. If we click on the VM in the server view, we can see the summary. It’s not very exciting yet because our machine is not running.

I’ve highlighted the buttons we are going to use next in the image above. Start is going to start the VM, and we’ll need to open the Console to see what’s going on. Go ahead and click both of these now, and sit back in amazement.

What happens next depends on what OS you are installing into this VM. You’ll just need to work your way through the questions accordingly. One point worth noticing though is that if is asks you questions like “Use the entire disk”, it’s talking about the virtual disk you allocated - not the physical disk.

This operating system you’re installing now doesn’t know it’s inside a virtual machine. Everything it sees - the machine bios, the screen, the memory - it’s all faked - and managed by Proxmox. You and Proxmox are playing god here. From the VM point of view, it could be installed directly on hardware. It doesn’t know the true nature of it’s world.

While you are killing time waiting for your new OS to install, if you haven’t used noVNC before, it’s worth noticing the little slide in options on the left edge there.

I most commonly use it to force this window fullscreen, but in the “Extra Keys” button might be handy if you’re running a Windows OS and want the Windows key. I don’t love this console window - I’d rather SSH in and use my terminal, but it’s a handy tool that’s always going to work if the VM is running.