=== ssh0732 is now known as ssh073
=== scoobydoo_ is now known as scoobydoo
[12:04] <ahasenack> morning
[12:04] <athos> ahasenack: morning :)
[12:08] <ahasenack> hi athos
[14:15] <lotuspsychje> flaf: did you get answered yet on your issue?
[14:18] <flaf> Hi lotuspsychje. Not yet unfortunately. According to this comment https://bugs.launchpad.net/subiquity/+bug/1946609/comments/2 , I think the feature exists but I have not found.
[14:18] <ubottu> Launchpad bug 1946609 in subiquity "Error when I purge snapd package in late-commands" [Undecided, New]
[14:21] <lotuspsychje> you filed the bug flaf ?
[14:26] <flaf> lotuspsychje: in fact it's a old bug I had filed and during the discussion I have said "to avoid my problem, it was cool if an option could allow a minimal install". And someone tells me "the option exists now since Ubuntu 21.10".
[14:27] <flaf> lotuspsychje: I would to deploy Ubuntu 22.04 now and I would like to use this feature (a minimal install) by I have found no info concerning this feature in the documentation of Subiquity.
[14:28] <lotuspsychje> i see flaf maybe the volunteers here might guide you to the best road
[14:31] <ahasenack> flaf: can you try 22.04 in a vm and see if the option is there, and if it does what you need?
[14:31] <flaf> lotuspsychje: yes. I had some private messages with dbungert, which is a dev of Subiquity. He helped me very well and, in return, I have filed some bugs. ;) But he doesn't seem to be present on this chan anymore.
[14:34] <flaf> ahasenack: This feature ("minmal" install) is present via a non interactive install (tested, I put the CD and answer to the questions...). But, in my case, I try a full automatic install via a user-data file (Subiquity/cloud-init/curtin etc). By this way, I have not found the option in user-data file to select a minimal install.
[14:35] <flaf> ahasenack: I hope I'm clear...
[14:36] <flaf> oups... this feature is present via an *interactive* install... But not found via user-data file (ie full automatic install).
[14:37] <ahasenack> ok
[16:08] <jrwren> e2fsck says a fs is in use. it doesn't show as mounted. I can mount it and unmount it. I cannot lvchange -a n it. reboot will probably fix it, but I'm trying to skip that.  What to do?
[17:01] <ahasenack> what about /proc/mounts?
[17:16] <ygk_12345> HI all
[17:16] <ygk_12345> i am trying to set systemd service overrides by issuing the command systemctl edit <service-name>
[17:17] <ygk_12345> but the the value for LimitNOFILESoft is not changing even after systemstl daemon-reload.
[17:17] <ygk_12345> its ubuntu 20.04. how to modify limits only for a specific process ?
[17:17] <ygk_12345> i dont want global change
[17:18] <ygk_12345> I mean for systemd specific service only
[17:20] <daum> i'm on 20.04 on a server and recently started getting packet loss.  Looking at the output of ifconfig i see the dropped count slowly increasing.  Any ideas what i could look at to try to resolve this?  
[17:21] <sdeziel> ygk_12345: could you share the `systemctl cat <service-name>` output via pastebin?
[17:22] <ygk_12345> sdeziel i dont have it handy right now.  But the LimitNOFILESOft is set to 1024. i want to change it to 2048 for that service only
[17:25] <sdeziel> ygk_12345: then having the following in the override snippet should work: https://termbin.com/ejo5
[17:26] <ygk_12345> @sd
[17:26] <ygk_12345> sdeziel bu it is not working even after a reload and a restart
[17:27] <ygk_12345> sdeziel still systemctl show service  is reporting old values only
[17:31] <sdeziel> ygk_12345: LimitNOFILESoft is not a valid name (there is no Soft suffix) so maybe that's the problem? Without seeing the cat output, it's hard to be sure
[17:31] <ygk_12345> sdeziel its exactly this "{LimitNOFILESoft"
[17:32] <ygk_12345> "LimitNOFILESoft"
[17:38] <sdeziel> ygk_12345: my bad, "LimitNOFILESoft" is valid, but it doesn't show in `man systemd.exec` which is weird. I think it's still worth trying with "LimitNOFILE"
[17:39] <ygk_12345> sdeziel "LimitNOFILE" is hard limit
[17:39] <ygk_12345> sdeziel i want to increase only the soft limit
[17:40] <sdeziel> ygk_12345: `man systemd.exec` says: > Set soft and hard limits on various resources for executed processes.
[17:42] <ygk_12345> sdeziel maybe I can try this "colon-separated pair soft:hard"
[17:43] <sdeziel> ygk_12345: I just tested and using `LimitNOFILE=2048:524288`, gives me LimitNOFILE=524288 and LimitNOFILESoft=2048
[17:43] <ygk_12345> sdeziel ok i will try it. thanks so much for your time and help. Have a nice day ahead :)
[17:44] <sdeziel> ygk_12345: you are welcome, you too
[17:56] <sdeziel> apt-get crashes one of my server no matter what I do with it https://termbin.com/gt0o. It started crashing after a power outage but a fresh `btrfs strub` says it's all clean, any ideas?
[17:56] <sdeziel> and dmesg had this: traps: apt-get[1783701] general protection fault ip:7e3cf64bef7b sp:7ffd15913248 error:0 in libc-2.31.so[7e3cf649e000+178000]
[17:57] <ahasenack> jammy or kinetic?
[17:57] <sdeziel> ahasenack: sorry, 20.04
[17:58] <sdeziel> libc6 was upgraded on May 11th: Upgrade: libc6:amd64 (2.31-0ubuntu9.7, 2.31-0ubuntu9.9)
[17:59] <ahasenack> haven't seen that before
[17:59] <sdeziel> yeah, me neither and it only affects one of 3 machines I keep almost identical
[18:01] <sdeziel> I will try to downgrade using dpkg on old .deb
[18:04] <sdeziel> downgrading libc6:amd64 from 2.31-0ubuntu9.9 to 2.31-0ubuntu9.7 => didn't help :/
[18:10] <sdeziel> oh well, a reboot made it work and I can go back to 9.9 and it still works, sorry for the noiswe
[19:06]  * ahasenack is scared of the samba merge this cycle
[19:07] <sergiodj> how's it looking?
[19:09] <ahasenack> I'm just watching the traffic, and there were many many changes
[19:10] <ahasenack> I was waiting for it to calm down a bit, before tackling the merge
[19:10] <sergiodj> any news from the Debian side, or will we stay ahead of them?
[19:10] <ahasenack> at least the new maintainer is very active, and has no qualms with asking upstream when he sees something that feels wrong
[19:10] <ahasenack> debian moved on, they are on 4.16.x already (the new maintainer did it)
[19:10] <sergiodj> ah, great
[19:11] <ahasenack> he is making many changes to the build system
[19:11] <ahasenack> the package build, that is
[19:11] <sergiodj> right
[19:11] <ahasenack> which is where the delta hurts
[19:11] <ahasenack> we still have i386 delta
[19:11] <ahasenack> I wonder when we will get rid of i386 for goot
[19:11] <ahasenack> good*
[19:11] <sergiodj> interesting.  I will try to check what happened during these last few months
[19:11] <sergiodj> ah, i386...  never ending story
[19:12] <patdk-lap> holdoff till I can kill frontpage? :)
[19:13] <sergiodj> FWIW openldap 2.6 also changed libldap's soname, which will require a new binary package
[19:13] <ahasenack> I actually had to think for one or two seconds for that one
[19:13] <ahasenack> frontpage
[19:13] <ahasenack> sergiodj: that's fine
[19:13] <patdk-lap> :)
[19:13] <sergiodj> yeah
[19:13] <ahasenack> first thing I remembered were frontpage exploits, access.log full of some fp? links
[19:13] <sergiodj> I'm double check everything because I don't want to mess up this rename
[19:14] <patdk-lap> ya, it is suppose to have root on the server, in each clients web space :(
[19:14] <sergiodj> s/check/checking/
[19:14] <patdk-lap> mine is hacked to run as a normal cgi under normal user permissions
[19:14] <patdk-lap> should see how many customers are logging into it still
[20:35] <ahasenack> sergiodj: I think openldap is failing to do sasl digest-md5 authentication (yes, quite obscure)
[20:35] <ahasenack> I was just trying with postfix (another server I know uses cyrus-sasl2), and it works there, so I'm about to rule out a cyrus-sasl2 bug
[20:35] <ahasenack> but will test openldap with previous cyrus-sasl2 now
[20:36] <sergiodj> ahasenack: OK, thanks for the heads up
[20:36] <ahasenack> getting postfix to work with sasl auth was "interesting", since it defaults to a chroot
[20:36] <ahasenack> and I think I found a bug in the way it prepares that chroot
[20:37] <ahasenack> it copies files into it without preserving the permission
[20:37] <ahasenack> so my secrets file was copied over and made 0644 (!)
[20:38] <sergiodj> ahasenack: kinetic, right?
[20:38] <ahasenack> yes
[20:38] <sergiodj> let me see if I can find a bug in the upstream bugzilla
[20:38] <sergiodj> although, as you said, it's very obscure
[20:39] <ahasenack> and openldap is deeming digest-md5 obsolete/insecure, so I'm unsure if they will even want to check it
[20:39] <ahasenack> but hey, got a dep8 failure about it
[20:39] <ahasenack> tests/test_ldapconnection.py::test_bind_digest Fatal Python error: Segmentation fault
[20:43] <sergiodj> found two bugs with "digetst-md5" in their comment sections, but they don't seem related to the error you're mentioning
[20:47] <sarnold> if that's on a github-hosted repo, https://github.com/check-spelling/check-spelling  might be a nice suggestion :)
[20:49] <ahasenack> your highlight rules are a mistery to me :)
[20:51] <sarnold> alas, it's much less sophisticated than that, it's just if the most recent few lines in a channel look interesting..
[20:51] <sarnold> and 'md5' surely stands out as 'interesting' :)
[20:54] <ahasenack> no typo there either :)
[20:57] <sarnold> alas they got that part right! :D
[21:00] <ahasenack> hm, found other bugs
[21:00] <ahasenack> the openldap cli utilities no longer take -h for hostname
[21:01] <ahasenack> that explains this I"m seeing in tests: "ldapwhoami: unrecognized option -�"
[21:01] <ahasenack> alas, it's not failing the tests
[21:01] <ahasenack> script is not run with set -e
[21:02] <sergiodj> I don't remember seeing this in the release notes
[21:02] <sergiodj> huh
[21:04] <ahasenack> ok, got digest-md5 working with previous cyrus
[21:06] <ahasenack> and with the new one, the client core dumps
[21:06] <ahasenack> grumbl
[21:09] <ahasenack> https://pastebin.ubuntu.com/p/qxygkxddjJ/
[21:10] <ahasenack> before I EOD, let me check if I can at least see if the crash is inside openldap or cyrus
[21:11] <ahasenack> oh, plot twist
[21:11] <ahasenack> it's in libssl3
[21:11] <sergiodj> hahah
[21:12] <sergiodj> oh, man
[21:12] <ahasenack> I mean, libcrypto.so.3
[21:12] <ahasenack> I meant to say openssl3
[21:12] <sergiodj> right
[21:12] <ahasenack> #0  0x00007ffff740854b in EVP_EncryptUpdate () from /lib/x86_64-linux-gnu/libcrypto.so.3
[21:12] <ahasenack> #1  0x00007ffff70a07a9 in ?? () from /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so
[21:12] <ahasenack> will install debug symbols tomorrow
[21:12] <sergiodj> where's debuginfod again?!
[21:12] <ahasenack> slacking
[21:13] <ahasenack> tsc, tsc
[21:13] <ahasenack> I keep reading it as debug info fod
[21:13] <ahasenack> or debugin fod
[21:13] <sergiodj> yeah, some people say "debug infod"
[21:13] <sergiodj> heh
[21:13] <sergiodj> bad naming
[21:13] <ahasenack> correct is debuginfo d, right?
[21:13] <ahasenack> as in debuginfo daemon?
[21:13] <sergiodj> yes
[21:13] <ahasenack> k
[21:16] <ahasenack> postfix digest-md5 worked, but it didn't setup a security layer (ssf was zero)
[21:16] <ahasenack> ldap sets a security layer, ssf=128 
[21:16] <ahasenack> and something goes wrong
[21:16] <ahasenack> postfix digest-md5, showing it worked, but ssf=0: https://pastebin.ubuntu.com/p/R5xNQnYKJ2/
[21:17] <ahasenack> and if I try to force it, it doesn't auth
[21:17] <ahasenack> "too weak": https://pastebin.ubuntu.com/p/f9HG3MH2Nm/
[21:20] <sergiodj> sorry, I'm pulling my hair out a little bit with Breaks/Conflicts/Replaces and the new openldap library name
[21:21] <ahasenack> ah, no, I'm just thinking out loud
[21:21] <sergiodj> yeah, please keep going
[21:21] <sergiodj> it's fun watching a live debug session
[21:21] <sergiodj> :)
[21:22] <ahasenack> if I disable the security factor (i.e., ssf=0), then digest-md5 works with ldap just like it did for postfix (where it was zero)
[21:22] <ahasenack> ubuntu@k1-sasl-digest-ldap:~$ ldapwhoami  -U ubuntu@lxd -w ubuntusecret -O maxssf=0
[21:22] <ahasenack> SASL/DIGEST-MD5 authentication started
[21:22] <ahasenack> SASL username: ubuntu@lxd
[21:22] <ahasenack> SASL SSF: 0
[21:22] <ahasenack> dn:uid=ubuntu@lxd,cn=vms,cn=digest-md5,cn=auth
[21:22] <ahasenack> ubuntu@k1-sasl-digest-ldap:~$ 
[21:22] <ahasenack> no core dump
[21:23] <ahasenack> ok, probably have enough for tomorrow
[22:08] <octav1a> I have a raid1 mdadm with two disks. I don't see any I/O errors in dmesg. For some reason, when rebooting the machine safely with sudo reboot, when it comes back up I still get a "recovery" process every time in /proc/mdstat
[22:08] <octav1a> Does anyone know why this happens?
[22:09] <octav1a> they are SSD so I feel this is putting undue wear on them
[23:17] <patdk-lap> must not be rebooting correctly? never seen a recovery thing in mdstat due to a reboot
[23:18] <patdk-lap> how did you configure md?
[23:19] <sdeziel> I remember some (old) bug where something was not properly umounted causing this behavior