[00:05] <g4mbit> JanC cool thanks, I'm giving this config a shot: https://bpa.st/TSPVI
[00:08] <JanC> I've never done that myself  :)
[00:09] <JanC> I use the client-side equivalent of it though
[00:21] <g4mbit> JanC like an authenticator app you mean?
[00:23] <JanC> no, I mean the client side equivalent of changing configuration based on certain matched parameters
[00:26] <JanC> e.g. allowing certain deprecated encryption algorithms to connect to an old NAS only, or setting up port forwarding to a database server so that I can connect to the remote database "locally"
[00:27] <g4mbit> oh ok got it 
[00:27] <JanC> changing authentication methods is just another thing to change
[00:28] <g4mbit> I'm still debating if I want to enable it, which will require me to have to remember to take this key anywhere I go
[00:28] <g4mbit> seems like yet another item I could forget to take 
[00:29] <g4mbit> phones to me seem so much natural since you already carry them anyway 
[00:31] <g4mbit> I'm considering using OTP instead with like google authenticator
[00:32] <JanC> you could also make it that one method always works and another method only works from LAN, or whatever
[00:33] <JanC> if necessary, using multiple daemons
[00:36] <g4mbit> cool, will think about it since like would be nice to use yubikey but without having to remember to take it everywhere lol
[04:21] <robertparkerx> if I upgrade ubuntu to 22.04 LTS will it keep my settings for things like apache2, varnish, etc. ?
[04:25] <robertparkerx> php
[04:25] <robertparkerx> I understand the versions might change
[06:47] <Exterminador> robertparkerx: when upgrading, all your current packages will be upgraded also, exception for third party PPAs. be aware, that for example, wordpress doesn't have yet (AFAIK) total support for PHP 8.1
[06:51] <Exterminador> robertparkerx: if you want to keep all your PPAs (exception goes for those that are deprecated/unsupported), you need to: `RELEASE_UPGRADER_ALLOW_THIRD_PARTY=1 do-release-upgrade`
[06:53] <Exterminador> once again, you may still see a warning about third party sources being disabled on upgrade, but those that support the Ubuntu version to which you're upgrading will not be disabled
=== mfo_ is now known as mfo
[14:57] <Arlion> I have a hypervisor running CentOS 7, all patches vs ubuntu 20. The hypervisor is running Ubuntu 20.04. The CentOS 7 kvm hosted vm is only able to 66% cpu utilization during stress test. Where the other guests are able to 100% cpu utilization. Any ideas. I confirmed the kvm params are identical to both guests. 
[14:57] <Arlion> I'm starting to think maybe there is a legacy param i need to enable to fully support the older operating system.
[14:57] <Arlion> Any ideas?
[15:00] <ahasenack> are you using virtio drivers?
[15:01] <ahasenack> in the guest
[15:06] <Arlion> looking
[15:09] <Arlion> confirmed, the centos 7 image is using virtio drivers
[17:26] <pvh_sa> Hi folks... I had a power cut here recently and after it one of my servers didn't come up right. This is a ubuntu 18.04 (upgraded from 16.04) that uses two Intel SSDSC2BB08 80 GB SSDs in RAID-1 as the boot drive
[17:28] <tomreyn> hi pvh_sa. if you're looking for assistence with this (not just sharing an experience), more details will be needed, such as ... what does "didn't come up right" mean.
[17:28] <pvh_sa> on the machine that fails it complains that it cannot find /dev/md* - one an identical machine that works, /proc/mdstat shows a container md with two mds - OS and SWAP - see here: https://gist.github.com/pvanheus/a9f7f17e47d89fb8c7bccdcd7b20713f
[17:30] <pvh_sa> both the working machine and the failed machine seem to have the same kind of md config - mdadmn (on the not-working machine running from a rescue boot disk) shows a metadata=imsm container with two drives like this https://gist.github.com/pvanheus/fef691a08cf24561780a02d32ad1dd0f
[17:30] <pvh_sa> sorry @tomreyn - was still typing - nearly done with the description
[17:30] <tomreyn> i noticed i was asking too quickly :) keep going...
[17:34] <pvh_sa> the two component drives are /dev/sda and /dev/sdb - and mdadm --examine shows them have two subarrays - https://gist.github.com/pvanheus/e675d1d39ab5befc1f5aee640c00d5fb - so far, so good, right? but when I create (in the rescue boot) a /etc/mdadm.conf with DEVICE lines for /dev/sda and /dev/sdb and the ARRAY config as output put mdadmin --examine --scan, and I try and activate it with mdadm -As --auto=yes --run -v, it says that it cannot find a RAID 
[17:34] <pvh_sa> superblock on any of /dev/sda or /dev/sdb
[17:34] <tomreyn> personally i won't be able to help because i lack experience with IMSM meta data raid.
[17:35] <pvh_sa> can't cut and paste that but image of the log is here https://pasteboard.co/C8TJTp0bgDnf.png
[17:36] <pvh_sa> (kernel on the failed machine is 4.15 - I'm using a rescue boot with kernel 5.15 to examine things)
[17:36] <pvh_sa> thanks @tomreyn - I think this was the default config back in the day when the machines were set up but seems to not be a common config these days :| certainly googling isn't yielding much
[17:38] <tomreyn> https://raid.wiki.kernel.org/index.php/RAID_setup#External_Metadata_.282011.29
[17:38] <tomreyn> "The second format is the Intel(r) Matrix Storage Manager metadata format." ...
[17:39] <tomreyn> You're storing the important metadata on the mainboard, the data itselfg (which can only be accessed with the metadata) on the disks. meaning you have a double hardware dependency. is that a good idea?
[17:41] <tomreyn> maybe that's not the right time to ask this question, but you should ask it once your data is accessible again
[17:42] <pvh_sa> the metadata is on the mainboard? wow. ok... that actually gives me a clue of where to look. the problem might well not be in the OS level then
[17:48] <pvh_sa> ok... `mdadm --detail-platform` shows something different on the working server vs the non-working one. going to check in BIOS to see if I can see anything
[17:59] <pvh_sa> and checking the BIOS the working machine has SATA set to RAID mode and the not working one has it on AHCI - I wonder if the BIOS battery failed and settings got reset to default
[18:01] <tomreyn> at least on consumer boards you'd usually see it default to RAID mode (and would probably want to change that to AHCI to prevent the issue discussed above)
[18:07] <pvh_sa> yeah this is a Supermicro server board - just rebooting it with that setting changed and it booted! thank you so much for the tip!! going to write this up in our Confluence 
[18:09] <tomreyn> and while you're at it, reconsider this setup ;)
[18:11] <pvh_sa> oh absolutely! btw it also came up with /dev/sdX names changed.. and the (legacy) ceph config I've got on here is thus all full of incorrect and broken symlinks
[18:13] <pvh_sa> (and we're into one of our regular power cut slots (luckily the server room generator is holding this time) so I think this is a good signal to take a break and watch some TV)
[18:13] <pvh_sa> thanks once again
[19:06] <tomreyn> heh, you're welcome, enjoy your tv night.