=== ssh0732 is now known as ssh073 | ||
=== scoobydoo_ is now known as scoobydoo | ||
ahasenack | morning | 12:04 |
---|---|---|
athos | ahasenack: morning :) | 12:04 |
ahasenack | hi athos | 12:08 |
lotuspsychje | flaf: did you get answered yet on your issue? | 14:15 |
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:18 |
lotuspsychje | you filed the bug flaf ? | 14:21 |
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:26 |
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:27 |
lotuspsychje | i see flaf maybe the volunteers here might guide you to the best road | 14:28 |
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:31 |
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:34 |
flaf | ahasenack: I hope I'm clear... | 14:35 |
flaf | oups... this feature is present via an *interactive* install... But not found via user-data file (ie full automatic install). | 14:36 |
ahasenack | ok | 14:37 |
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? | 16:08 |
ahasenack | what about /proc/mounts? | 17:01 |
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:16 |
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:17 |
ygk_12345 | I mean for systemd specific service only | 17:18 |
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:20 |
sdeziel | ygk_12345: could you share the `systemctl cat <service-name>` output via pastebin? | 17:21 |
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:22 |
sdeziel | ygk_12345: then having the following in the override snippet should work: https://termbin.com/ejo5 | 17:25 |
ygk_12345 | @sd | 17:26 |
ygk_12345 | sdeziel bu it is not working even after a reload and a restart | 17:26 |
ygk_12345 | sdeziel still systemctl show service is reporting old values only | 17:27 |
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:31 |
ygk_12345 | "LimitNOFILESoft" | 17:32 |
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:38 |
ygk_12345 | sdeziel "LimitNOFILE" is hard limit | 17:39 |
ygk_12345 | sdeziel i want to increase only the soft limit | 17:39 |
sdeziel | ygk_12345: `man systemd.exec` says: > Set soft and hard limits on various resources for executed processes. | 17:40 |
ygk_12345 | sdeziel maybe I can try this "colon-separated pair soft:hard" | 17:42 |
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:43 |
sdeziel | ygk_12345: you are welcome, you too | 17:44 |
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:56 |
ahasenack | jammy or kinetic? | 17:57 |
sdeziel | ahasenack: sorry, 20.04 | 17:57 |
sdeziel | libc6 was upgraded on May 11th: Upgrade: libc6:amd64 (2.31-0ubuntu9.7, 2.31-0ubuntu9.9) | 17:58 |
ahasenack | haven't seen that before | 17:59 |
sdeziel | yeah, me neither and it only affects one of 3 machines I keep almost identical | 17:59 |
sdeziel | I will try to downgrade using dpkg on old .deb | 18:01 |
sdeziel | downgrading libc6:amd64 from 2.31-0ubuntu9.9 to 2.31-0ubuntu9.7 => didn't help :/ | 18:04 |
sdeziel | oh well, a reboot made it work and I can go back to 9.9 and it still works, sorry for the noiswe | 18:10 |
* ahasenack is scared of the samba merge this cycle | 19:06 | |
sergiodj | how's it looking? | 19:07 |
ahasenack | I'm just watching the traffic, and there were many many changes | 19:09 |
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:10 |
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:11 |
patdk-lap | holdoff till I can kill frontpage? :) | 19:12 |
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:13 |
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 | 19:14 |
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:35 |
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:36 |
ahasenack | it copies files into it without preserving the permission | 20:37 |
ahasenack | so my secrets file was copied over and made 0644 (!) | 20:37 |
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:38 |
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:39 |
sergiodj | found two bugs with "digetst-md5" in their comment sections, but they don't seem related to the error you're mentioning | 20:43 |
sarnold | if that's on a github-hosted repo, https://github.com/check-spelling/check-spelling might be a nice suggestion :) | 20:47 |
ahasenack | your highlight rules are a mistery to me :) | 20:49 |
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:51 |
ahasenack | no typo there either :) | 20:54 |
sarnold | alas they got that part right! :D | 20:57 |
ahasenack | hm, found other bugs | 21:00 |
ahasenack | the openldap cli utilities no longer take -h for hostname | 21:00 |
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:01 |
sergiodj | I don't remember seeing this in the release notes | 21:02 |
sergiodj | huh | 21:02 |
ahasenack | ok, got digest-md5 working with previous cyrus | 21:04 |
ahasenack | and with the new one, the client core dumps | 21:06 |
ahasenack | grumbl | 21:06 |
ahasenack | https://pastebin.ubuntu.com/p/qxygkxddjJ/ | 21:09 |
ahasenack | before I EOD, let me check if I can at least see if the crash is inside openldap or cyrus | 21:10 |
ahasenack | oh, plot twist | 21:11 |
ahasenack | it's in libssl3 | 21:11 |
sergiodj | hahah | 21:11 |
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:12 |
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:13 |
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:16 |
ahasenack | and if I try to force it, it doesn't auth | 21:17 |
ahasenack | "too weak": https://pastebin.ubuntu.com/p/f9HG3MH2Nm/ | 21:17 |
sergiodj | sorry, I'm pulling my hair out a little bit with Breaks/Conflicts/Replaces and the new openldap library name | 21:20 |
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:21 |
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:22 |
ahasenack | ok, probably have enough for tomorrow | 21:23 |
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:08 |
octav1a | they are SSD so I feel this is putting undue wear on them | 22:09 |
patdk-lap | must not be rebooting correctly? never seen a recovery thing in mdstat due to a reboot | 23:17 |
patdk-lap | how did you configure md? | 23:18 |
sdeziel | I remember some (old) bug where something was not properly umounted causing this behavior | 23:19 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!