New Pages:

Ansible: Basic Usage

Edited Pages:

Linux Setup: Hostname and Static IP

• Changed section titles for more accuracy

Linux: SSH Renamed to SSH

Linux: Sudoers

• Added new section: Specify Permissions

This lab was an absurd series of tech issues, with no clear cause. It started out smoothly, with no real problems for the first half, but I encountered three major problems during the second half.

For one deliverable, I attempted to deploy the ansible role rbicker.nextcloud. It worked, in the sense that the role was deployed, but the Nextcloud installation seems broken - upon logging in, it would redirect back to the login page - turns out this is an issue that many people have encountered in Nextcloud versions 16 through at least 19, with many different possible causes and solutions. What I did was change the owner of the directory /var/lib/php/session/ to nginx, and reboot, then it worked, but figuring that out was a painful process:

Note that these are just what were open when I finally solved it, not the full list of pages I looked through.

• Nextcloud 16.0.1 Login Loop on Install (this is the one that worked for me)
• Endless login loop on NextCloud via browser
• Stuck in a login loop when logging in from sync client on Linux
• Login loop in fresh installation of Nextcloud 18
• [solved] Nextcloud Desktop Client 2.5.2 Login Loop fails with Nextcloud 16.0.1 works with Nextcloud 15
• Nextcloud 19.0.1 login redirect loop

I put the Nextcloud problem on hold - it did successfully run the Ansible playbook, after all, and I wanted to get through the rest of the lab before taking time to troubleshoot it. Unfortunately, the next part of the lab was to set up OpenSSH on two Windows machines, wks01-eli and mgmt01-eli. Things went smoothly on mgmt01-eli, but whenever I tried to SSH into wks01-eli, I got an error reading connection reset by 10.0.150.0 port 22, and I could not figure out why. I decided to sleep on it, and the next morning, the error had stopped, but I ran into another error - I could only SSH in to wks01-eli if I was also logged in on wks01-eli - I'm guessing that was because wks01-eli is a workstation, not a server. This was not a big deal, I just had to make sure to log back in if the session locked.

This one was the worst of the bunch, and it is one that I decided to take screenshots of. I had to use Ansible from controller-eli (an Ubuntu system) to install Firefox, 7-zip, and Notepad++ on mgmt01-eli (Windows Server 2019) and wks01-eli (Windows 10). (Link to the playbook I used.) That would be easy enough, if it weren't for the fact that there seems to be some strange issue with the way env vars are handled by OpenSSH on Windows, resulting in the following error:

Please forgive the typo in the task name

I am not the only one to encounter this - here are some issue reports I found on it:

• chocolatey/chocolatey-ansible#22
• chocolatey/chocolatey-ansible#34
• ansible/ansible#68179

What really confused me, though, is what happened when I got fed up with that, and tried to manually install Chocolatey:

So, it seems that Chocolatey was detected as being installed by the installer, but not by the actual system. What I then tried, and what did work, was deleting the direcory C:\ProgramData\chocolatey, then running the installer.

All things considered, this was a massive headache of a lab.