We’ve got 43 maple trees and two black walnut trees tapped. 18 maples were tapped yesterday in the back woods (plus the one right by the driveway).
The big maple by the river, that I’ve been waiting to tap since we found it … had nothing! Hopefully sap starts flowing there too. The other trees, though, were drip, drip, dripping steadily
We have a number of applications that authenticate to Active Directory. Invariably, when there are authentication issues, the vendor support person asks “what version of AD is this?” … not an unreasonable question, but also not something the person who supports Application XYZ is apt to know in a larger company. Fortunately, there are a few places within the directory that you can find details about AD versions.
The simplest is the version of Windows the domain controllers are running … although it’s possible domain controllers have been upgraded but the AD functional level has not yet been changed.
ldapsearch -h ad.example.com -D "ldapquery@example.com" -w "P@s54LD@pQu3ry" -p389 -b "ou=domain controllers,dc=example,dc=com" "(&(objectClass=computer))" operatingSystem
CN=dc007,OU=Domain Controllers,dc=example,DC=com
operatingSystem=Windows Server 2019 Datacenter
CN=dc008,OU=Domain Controllers,dc=example,DC=com
operatingSystem=Windows Server 2019 Datacenter
CN=dc020,OU=Domain Controllers,dc=example,DC=com
operatingSystem=Windows Server 2019 Datacenter
CN=dc021,OU=Domain Controllers,dc=example,DC=com
operatingSystem=Windows Server 2019 Datacenter
You can also find the objectVersion of the schema:
ldapsearch -h ad.example.com -D "ldapquery@example.com" -w "P@s54LD@pQu3ry" -p389 -b "cn=schema,cn=configuration,dc=example,dc=com" "(&(objectVersion=*))" objectVersion
CN=Schema,CN=Configuration,dc=example,DC=com
objectVersion=88
What does 88 mean? It depends! Either Windows 2019 or 2022
| Version | Operating System |
|---|---|
| 13 | Windows 2000 Server |
| 30 | Windows Server 2003 (Before R2) |
| 31 | Windows Server 2003 R2 |
| 44 | Windows Server 2008 (Before R2) |
| 47 | Windows Server 2008 R2 |
| 56 | Windows Server 2012 |
| 69 | Windows Server 2012 R2 |
| 87 | Windows Server 2016 |
| 88 | Windows Server 2019 |
| 88 | Windows Server 2022 |
Or the functional level of the forest and its partitions:
ldapsearch -H ldap://ad.example.com -D "ldapquery@example.com" -w "P@s54LD@pQu3ry" -b "cn=partitions,cn=configuration,dc=example,dc=com" "(&(MSDS-Behavior-Version=*))" MSDS-Behavior-Version
dn: CN=Partitions,CN=Configuration,DC=example,DC=com
msDS-Behavior-Version: 7
dn: CN=EXAMPLE,CN=Partitions,CN=Configuration,DC=example,DC=com
msDS-Behavior-Version: 7
What does 7 mean? Well, that depends too. It’s either Windows 2016 or 2019!
| msDS-Behavior-Version | Forest |
Domain | Domain Controller |
| 0 | 2000 | 2000 Mixed / Native | 2000 |
| 1 | 2003 Interim | 2003 Interim | N/A |
| 2 | 2003 | 2003 | 2003 |
| 3 | 2008 | 2008 | 2008 |
| 4 | 2008 R2 | 2008 R2 | 2008 R2 |
| 5 | 2012 | 2012 | 2012 |
| 6 | 2012 R2 | 2012 R2 | 2012 R2 |
| 7 | 2016 | 2016 | 2016 |
| 7 | 2019 | 2019 | 2019 |
We saw the first turkey vultures of the year today. Counting down until March 15th when the Wizard of Hinckley turns them all into buzzards!
Quick command to list each running VM and the vnet that is associated to the VM
for vm in $(virsh list | grep running | awk '{print $2}'); do echo -n "$vm:"; virsh dumpxml $vm| grep -oP "vnet\d+" ; done
There have been a few times I’ve needed to make a custom build of an application — to enable some feature that the default build does not include or to use a newer version than is available in the package repository — and I always thought it would be really useful to know what the build parameters were. Turns out you can find how Fedora packages were build.
Go to https://koji.fedoraproject.org and search for the package
Locate ‘yours’ – the right version of the application and the right version of Fedora – and click on the package name
Scroll down to the “Logs” section – click on the “build.log” for the proper architecture
Here, you will see the entire log for building the RPM but part of that is building the application from source. You’ll be able to find the configuration and make parameters used in the build. As an example, I was trying to determine if Gerbera was build with the REUSEADDR flag (it was) and LIBUPNP disable-blocking-tcp-connections
https://kojipkgs.fedoraproject.org//packages/gerbera/2.0.0/1.fc39/data/logs/x86_64/build.log
In my particular case, I then had to find the libupnp package and see how that was built – they’ve got enable blocking tcp connections. Reusing the parameters from the RPM allows me to build packages that land files in “the right place” (or, rather, the place used in the Fedora package) and include any features they’ve included.
I started upgrading our Tableau servers to 2023.3 this week. Several dashboards no longer rendered after the upgrade — throwing an error “TableauException: Incorrect data type real, getting expected integer type.” … resetting or not resetting the view did not help.
This is evidently a known issue (although the documentation prior to my reporting the issue seemed to go out of its way to say it is just the cloud platform being impacted)
https://issues.salesforce.com/issue/a028c00000iwtkXAAQ/~
https://kb.tableau.com/articles/Issue/error-incorrect-data-type-real-getting-expected-integer-type-occurs-intermittently-during-view-rendering
Both the server and desktop client are impacted — and, unlike their documentation that says it is intermittent? Not all workbooks are impacted, but the ones that are? A broken workbook is broken and will not render for anyone, anywhere, any time.
There is a workaround:
Server:
tsm configuration set -k features.EnableLogicalQueryBatchProcessor -v false
tsm pending-changes apply
Desktop:
“\Program Files\Tableau\Tableau 2023.3\bin\tableau.exe” -DOverride=EnableLogicalQueryBatchProcessor:off
Someone deleted one of the packages from the Azure DevOps Maven feed … figured it would be easy enough to just re-publish the package. And they got an error:
409 Conflict – The version 1.2.3 of package.example.com has been deleted. It cannot be restored or pushed. (DevOps Activity ID: E7E4DEB1551D) -> [Help 1]
There’s some not-outlandish logic behind it because they don’t want half of the people to have this version 1.2.3 and the other half to get that version 1.2.3 … if it’s your code, just make it version 1.2.4. Unfortunately, this logic doesn’t hold up well when you’re publishing someone else’s package. Not like I can say “oops, we’ll use 23.13 now”. But you can restore deleted packages — from the feed, go into the recycle bin
Check off the packages that were deleted in error & restore them
After upgrading all of our Linux hosts to Fedora 39, we are running ISC bind 9.18.21 … and it seems the ISC folks are finally done with Microsoft’s “kinda sorta RFC compliance”. Instead of just working around Windows DNS servers having some quirks … they now fail to AXFR the domain.
Fortunately, you can tell bind to stop doing edns ‘stuff‘ by adding a server{} section to named.conf — this gives the server some instructions on how to communicate with the listed server. When bind is no longer trying to do edns “stuff”, Windows doesn’t have an opportunity to provide a bad response, so the AXFR doesn’t fail.
After upgrading to Fedora 39, we started having problems with Samba falling over on startup. The server has IPv6 disabled, and (evidently) something is not happy about that. I guess we could enable IPv6, but we don’t really need it.
Adding the following to lines to the GLOBAL section of the smb.conf file and restarting samba sorted it:
bind interfaces only = yes
interfaces = lo eth0
Feb 11 06:26:01 systemd[1]: Started smb.service – Samba SMB Daemon.
Feb 11 06:26:01 smbd[1109]: [2024/02/11 06:26:01.285076, 0] ../../source3/smbd/server.c:1091(smbd_open_one_socket)
Feb 11 06:26:01 smbd[1109]: smbd_open_one_socket: open_socket_in failed: Address family not supported by protocol
Feb 11 06:26:01 smbd[1109]: [2024/02/11 06:26:01.290022, 0] ../../source3/smbd/server.c:1091(smbd_open_one_socket)
Feb 11 06:26:01 smbd[1109]: smbd_open_one_socket: open_socket_in failed: Address family not supported by protocol
Feb 11 08:01:43 systemd[1]: Stopping smb.service – Samba SMB Daemon…
Feb 11 08:01:43 systemd[1]: smb.service: Deactivated successfully.
Feb 11 08:01:43 systemd[1]: Stopped smb.service – Samba SMB Daemon.
The /var partition was filling up with gigs of space in /var/spool/abrt — crash dumps. Luckily there’s a quick CLI command to review the dumps and remove any you don’t want to investigate farther.
abrt-cli rm /var/spool/abrt/*
You can use rm -f to avoid being prompted to confirm each deletion.
