Upgrading Ubuntu release from 22.04 to a new version fails with a warning that the Release for qgis does not exist and the upgrade fails. sudo do-release-upgrade Checking for a new Ubuntu release Hit http://security.ubuntu.com/ubuntu jammy-security InRelease Hit https://dl.google.com/linux/chrome/deb stable InRelease Ign https://ubuntu.qgis.org/ubuntu-ltr your-distributions-codename InRelease Err https://ubuntu.qgis.org/ubuntu-ltr your-distributions-codename Release 404 Not Found [IP: 144.76.174.102 443] Updating packages lists E: The repository ‘https://qgis.org/ubuntu-ltr your-distributions-codename Release’ does not have a Release file. Warning: apt-get update failed for some reason Error during update A problem occurred during the update. This is usually some sort of network problem, please check your network connection and retry.
Removing qgis does not resolve the problem. Doing an autoremove to purge unneeded packages does not resolve the problem. ppa-purge does not resolve the problem. Clearly there is a sources file somewhere that has not been removed. The qgis.sources file is not found in the location stated in on-line resources.
Use grep to search for the file. sudo grep -rnwI ‘/etc/’ -e ‘qgis‘ Files are found in subdirectories not mentioned in online searches thus far /etc/mime.types:1534:application/x-qgis /etc/default/qgis:1:# Options to pass to qgis /etc/apt/sources.list.d/qgis.sources:2:URIs: https://qgis.org/ubuntu-ltr /etc/apt/sources.list.d/qgis.sources:6:Signed-By: /etc/apt/keyrings/qgis-archive-keyring.gpg
Removing the qgis.sources and qgis files allowed an update to the new OS version to proceed.
The format to identify a user on the Ubuntu box is not obvious on the first attempt for a domain joined computer with active directory user accounts.
Normally you would use the format ssh user1@192.168.22.15 to connect. This works fine for local accounts not associated with active directory.
However, connecting to an active directory account needs a different format. You need to include the full active directory user name then add the computer address. It ends up looking strange but works. ssh aduser@jmw.blog@192.169.22.15 This connects and resolves to the AD user name on the computer. This works both with Ubuntu and with PuTTY.
Note that the active directory user must already be authenticated on the Ubuntu computer. The SSH protocol will not check authentication of a new user against active directory; it only checks the local status.
Left unfettered, the disk journal files can consume multiple GB of disk space. In mini systems with smaller SSDs this can lead to warnings that the disk is running out of space.
To find amount of disk space in use: journalctl –disk-usage Sudo is not needed
If you decide to delete journal files, first close and archive all active journal files: sudo journalctl –rotate
You can delete log files by age, disk space used or number of files to remain: sudo journalctl –vacuum-size=150M leaves 150MB of journal files sudo journalctl –vacuum-files=6 leaves 6 files sudo journalctl –vacuum-time=3days leaves the last 3 days of files
The amount of space taken up by journal files can be limited by editing the journald.conf file: sudo gedit /etc/systemd/journald.conf Uncomment line 25 SystemMaxUse and set a value. SystemMaxUse=150M A different editor is used in Ubuntu 23.04 but the configurations are the same.
Reload the configuration sudo systemctl restart systemd-journald
The problem is created by having the enhanced view active in the Hyper-V connection to the VM. This may express several ways and may not occur in all situations. Does happen in Hyper-V consoles on Windows 10, 11, server 2019 and probably other server versions. In some cases there will be no enhanced view option available and there is no issue. In other cases, the option has to be deselected every time. This is new behavior as it started with VMs that have been working without a problem.
Image of login screen when enhanced session is enabled. This happens when you do a Quick Create. When you complete the login, there is just a blank screen. Other times, with existing VMs, you may get normal login screen that fails with a blank screen – next image.
Image of login screen when enhanced view is off. This will be successful. Sometimes you may get this screen with the Enhanced Session checked and it will go to a blank screen on login. Notice the option cannot be checked in this instance.
If the Ubuntu box is active directory domain joined for user authentication, the domain users cannot authenticate without changes to the sssd.conf file. sudo -i cd /etc/sssd nano sssd.conf add 3 lines case_sensitive = False ad_gpo_access_control = enforcing ad_gpo_map_remote_interactive = +xrdp-sesman
restart sssd systemctl restart sssd
For domain user name use the full domain in this format. user@nameof.domain
Just discovered there is an option to join 22.04 to Active Directory when installing the OS. This worked smoothly and allowed immediate access authenticating against AD. The DHCP server must hand out a DNS address that works to resolve the domain name. Very important in home setups. There is no option to enter a different DNS server during setup. If it can’t find the AD server, the install will continue but without AD authentication.
The initial login screen shows only the local admin account created during setup. You need to select “not listed” and enter user@domain.name. If you just do the domain user name without the extension, it fails. After the local account setup is done, the domain user will appear as an option on the login screen.
If you use Quick Create in Windows 10/11 Hyper-V to make an Ubuntu VM, there is no option to domain join; you have to AD join manually following creation of the VM. Personally, I find it easier to manually create a VM and use auto join during install.
Caution if creating a virtual machine in Hyper-V. Be sure to first create an external virtual switch and assign it when configuring the VM. The default VM network connection is internal and will not connect to the AD domain controller. However, the test for connection will pass during configuration because setup is using the host network. It will fail during actual implementation because the VM is using its assigned virtual network switch, not the host.
To check which DNS servers Ubuntu uses: nmcli dev show | grep DNS
The following is how to domain join after the OS is installed or if you are using an earlier version that 22.04.
Ran thru a bunch of instruction sets for authenticating to a domain and the one below worked the first time and easy to implement. You might want use a test virtual machine first as you can brick it but I did live on real hardware, no problem. However, there are 2 gotchas left out of the instructions: First, before starting, add the computer to be joined to Windows DNS otherwise you get a lot of messages saying computer not found while following the instructions. However, it will join and authenticate. Second, you need to enable and start the systemd.resolved service once you’ve finished joining. My machine could not connect to the internet or authenticate at the GUI until that was done; however, the SSH connection in the demo did work. No issues after restarting the service. I’m not sure if it’s even necessary to disable the service but that’s for later.
He does go thru the commands fast and it’s sometimes difficult to stop on the text plus the font is small and hard to read, so here are the basics. Check the video for explanations.
First install all the required packages. sudo apt -y install realmd libnss-sss libpam-sss sssd sssd-tools adcli samba-common-bin oddjob oddjob-mkhomedir packagekit
Next stop the local DNS resolution and verify. sudo systemctl disable systemd-resolved.service then stop – just replace disable with stop then status – replace stop with status
Set host name to match AD schema hostname.sub.domain.extension e.g. ubuntu1.internal.bogus.org
Configure DNS sudo nano /etc/resolv.conf replace nameserver 127.0.0.1 with nameserver AD DNS server address
Test DNS connection realm discover internal.bogus.org
Enter name of computer into AD DNS otherwise get error message “unable to resolve hostname.sub.domain.bogus.org” It will still connect but error messages continue the thru rest of the process.
Join AD sudo realm join -U someADadmin internal.bogus.org You’ll get a prompt for the password. No output when successful.
Check you have joined realm list
Halfway done. Now you have to allow users to authenticate against AD and create home directories
Update pam sudo pam-auth-update check box for “Create home directory on login”
restart sssd sudo systemctl restart sssd sudo systemctl status sssd
allow AD users to login to the computer sudo realm permit –all
See video on how to make domain admins local sudo holders
Enable and restart DNS resolution or you have problems reaching the network and logging in
logout AD login by selecting “not listed?” enter AD user in the form: user@internal.bogus.org Caution on AD usernames that start with numbers or anything other than a letter, these violate Ubuntu naming standards.
Check the firewall on the unit hosting the controller. Port 8080 should be open for communication between the device and controller. Quick test is to drop the firewall and if that’s the problem, it will immediately start talking to the devices. Once they are found and brought up to date, enable the firewall. Communication will continue if port 8080 is open. I’ve had this happen twice on an Ubuntu box when I physically changed the switch port it was connected to and obtained a new IP address on the same subnet. This was with port 8080 open.
After another incident and watching the devices panel, it turns out that all devices need to be adopted again when the IP address of the controller changes. For device adoption port 10001/UDP needs to be open. Just tested this and it worked without having to drop the firewall.
There are several videos on installing Network UPS Tools (NUT) on the Raspberry Pi. The best detailed instruction I’ve seen is: https://www.youtube.com/watch?v=vyBP7wpN72c Note: this includes a fix for a Tripp-Lite problem However, this does not cover some specific instances where problems arise with multiple units from one manufacturer
There are 5 files to edit in order to get minimal functionality: nut.conf, ups.conf, uspd.conf, upsmon.conf, and upsd.users. There is a sixth for the web interface: hosts.conf. Some of these files contain interlocking information so what is in one file affects the function of another. That can make troubleshooting difficult when things to sideways.
Easy configs first. nut.conf contains a single line MODE = status. There are 4 possible entries with the default of none which is the off state. It can be standalone, netserver or netclient. Use netserver if you ever expect it feed information to another NUT installation. upsd.conf contains a single line LISTEN IPaddress port. This is for internal communication between various elements of a NUT install. Default is 127.0.0.1 3493.
upsd.user contains a block username with password and admin status either master or client. [username] password = xxxxxxxx admin master
More complex configs
ups.conf: contains the unit name, driver, port, description (optional) and unique product identification information. The description should look like this: [MyUPSname] driver = usbhid-ups port = auto desc = “CyberPower 1500” vendorid = 0764 productid = 0501 pollinterval = 15
For a single unit, vendorid and productid are adequate. If you have multiple units they must be distinguished by some combination of vendor, product, serial, vendorid and productid. Not all are necessary; just the ones that produce a unique identification. This can be difficult if you have multiple units from the same manufacturer as they may have the same vendorid and productid. sudo nut-scanner -UNwill produce the correct configuration that can be copied into the ups.conf file.
Here is where things get complicated for multiple units on a single monitor. You cannot always get a unique combination nor does nut-scanner always produce a working configuration. One complication is nut-scanner may produce a different result or fail for a unit when it is in combination with another as opposed to stand alone. Individually, the units can connect but cannot be successfully combined. I tested 6 CyberPower units. I was able to get 4 to function as two pairs but 2 units would never work in any combination. Part of the problem is some units do not produce a usable serial number and some will cause nut-scanner to fail when in combination with another unit. Seems that using the bus and device/port numbers together would work as a unique identifier then the vendorid and productid would be supplementary information for configuration but the input for port is limited to the tty terminal for serial connections and is ignored for USB. Following the digital trail, looks like Eaton took over the project but no longer supports it. They have what appears to be a competing product for sale so don’t expect any updates to NUT. The source code SKD and documents are available at Github https://github.com/networkupstools/nut/tree/Eaton_SDK
The video was an installation on a Raspberry Pi 4. I tried it on a Raspberry Pi 3+ Model B. NUT installed but did not include the nut-scanner command. Found some scattered information about the missing command but nothing concrete to solve the problem.
Vendorid and productid: You can get the Model and ProductID from the usb-devices command or from lsusb command. An example format for lsusb is Bus 001 Device 012: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS The 0764:0501 are the vendorid:productid which is adequate for a single ups connection. You can get more detail using lsusb -s 1:12 -v or lsusb -d 0764:001 -v If you use usb-devices, you may find the model name is not the same as found in lsusb description even though the vendorid and productid are the same.
pollinterval: After getting the correct driver, I installed the web server and successfully connected to the web page with the UPS data. However, it timed out and would display stale data warning after about 20 minutes. A quick check of the problem is torun sudo upsdrvctl start and the data refreshes. Troubleshooting information from other posts indicated that NUT and UPS were timing out at different intervals so NUT thought the UPS was offline and offered up a stale data warning. Fixing it led down several blind alleys. Turns out neither MAXAGE nor DEADTIME have any effect on this. You need to include pollinterval = 15 in the device description; it will not work outside the device description. This problem may be specific to CyberPower but may occur with others. driver:usbhid-ups is the only driver you can use with USB connected devices. Details are at: https://networkupstools.org/docs/man/usbhid-ups.html
upsmon.conf: contains the name of the unit to be monitored with @localhost, a digit, admin password and status MONITOR CyberPower@localhost 1 admin password master. The name comes from ups.conf file; the password comes from uspd.users. For the upsc command, just the name is adequate The digit is 0 if no UPS is powering the monitoring computer, 1 if a single UPS powers the monitoring computer. Higher numbers indicate the total UPS units powering the computer. If a computer has 4 UPS units powering it but only 2 are needed to provide adequate power, the shutdown command needs to be adjusted so it won’t trip when 1 UPS goes offline.
Web page:
Firewall: The Apache installation on the Raspberry Pi went smoothly and the firewall was automatically configured for the NUT web page. However, the Ubuntu machine had a UFW and automatic configuration did not occur. It was only necessary to open port 80 and it worked.
The usual instructions to connect from Windows via RDP to Ubuntu failed on18.0.4. The problem is a dependency in a needed package has been broken in the installation of XRDP on Ubuntu. The fix is to install xorgxrdp manually but it is missing dependencies so you have to install xserver-xorg-core first. However, that also uninstalls some packages needed for mouse and cursor control in an RDP session so you add them back with xserver-xorg-input-all. After that, you can install xorgxrdp manually and the connection works.
The web page with write up on details is: https://c-nergy.be/blog/?p=13390
The broken dependencies in XRDP seem to have been corrected in the 20.04 install.
Still some flakey stuff about color scheme authorization when you connect but that’s more of a nuisance.
Update 1 Aug 2021
Found the web site which correctly address the color scheme authorization problem. I used it for Ubuntu 20.04 since I had the same problem with it as I did with 18.0.4.
One gottcha is you have to log out of Ubuntu before you attempt the remote desktop, otherwise all you get is a blank screen. Likewise logout of Ubuntu when exiting the RDP session, otherwise you get a blank screen when trying to login in to the physical box. Reboot is necessary to clear it. Might be a command line session you can do from putty but rebooting is quick and easy.
For Raspberry Pi, the process is much easier. Just install XRDP. The connection spawns a new window so you can have one window on the Raspberry Pi while working on a completely different window in the RPD session.
Update 2 Nov 2022
For Ubuntu 22.04 the problems have been addressed and installation is trivially easy.
Change to the root account for all commands to work. sudo -i install xrdp apt install xrdp Add xrdp to the certificate. Must be root to work. usermod -a -G ssl-cert xrdp
Modify the firewall ufw allow 3389/tcp ufw allow 3389/udp
Logoff before trying RDP from windows. There will be 2 additional password authentications on connection to enable color pallet and color device management. This is for local users not AD users.
Active Directory authentication for RDP session
If the Ubuntu box is active directory domain joined for user authentication, the domain users cannot authenticate without some changes to the sssd.conf file. sudo -i cd /etc/sssd nano sssd.conf
add 2 lines ad_gpo_access_control = enforcing ad_gpo_map_remote_interface = +xrdp-sesman
restart sssd
For domain user name use the full domain in the format user@nameof.domain
Another option.
You can also go to settings, enable remote desktop, check enable legacy VNC protocol. This has slightly different login behavior with the authentication requests: one for color pallet and another for keyring unlock. However, the 2 procedures do not conflict and both can be active at the same time. You still get an xrdp login box under RDP.
I removed VNC and tried to connect with RDP and could not authenticate. RDP would not even connect to the remote machine unless I was logged in on the remote machine. This is xrdp behavior where you must be logged out to authenticate even though a connection can be made. From some posts, it appears this protocol is showing the same screen and the person logged in, not spawning a new one. After some more searching, this login failure appears to be a common problem with no definitive answer for now. Some people get it to work, others can’t.
Jerry's blog 