| xnox | vorlon, LocutusOfBorg - corosync in a lxd container seems sad. cannot start it on amd64 | 00:14 |
|---|---|---|
| xnox | at first seemed like low default limits: | 00:14 |
| xnox | lxc config set CONTAINER-NAME limits.kernel.memlock 33554432 | 00:14 |
| xnox | helped to get past one error in corosync, but now logs don't initialize, and i'm not sure why | 00:14 |
| xnox | May 08 00:10:42 nice-mako corosync[349]: [MAIN ] Can't initialize log thread | 00:15 |
| xnox | May 08 00:10:42 nice-mako corosync[349]: [MAIN ] Corosync Cluster Engine exiting with status 7 at main.c:1507. | 00:15 |
| xnox | or maybe worse. | 00:15 |
| sarnold | xnox: kinda looks like that needs posix semaphores https://sources.debian.org/src/libqb/1.0.4-2/lib/log_thread.c/?hl=142#L142 | 00:19 |
| sarnold | xnox: any idea if those work or are disallowed by your container? seccomp rules? | 00:20 |
| sarnold | .. hmm, or maybe it's the scheduling priority | 00:21 |
| xnox | hmmm | 00:21 |
| xnox | max locked memory (kbytes, -l) 65536 | 00:21 |
| xnox | max memory size (kbytes, -m) unlimited | 00:21 |
| xnox | i don't like this in ulimit -a | 00:21 |
| xnox | i think i need more | 00:21 |
| xnox | and i did do $ lxc config set nice-mako limits.kernel.memlock 6553600 | 00:21 |
| xnox | so why does my container not do more?! | 00:22 |
| sarnold | systemd can fiddle rlimit_memlock https://sources.debian.org/src/systemd/241-3/src/core/main.c/?hl=1376#L1376 | 00:23 |
| xnox | sarnold, sigh $ sudo systemctl edit snap.lxd.daemon.service | 00:30 |
| xnox | [Service] | 00:30 |
| xnox | LimitMEMLOCK=655360000 | 00:30 |
| xnox | and it looks like it doesn't respect units right.... | 00:30 |
| xnox | as if that's in bytes, instead of kb | 00:30 |
| * xnox tries a suffix | 00:30 | |
| xnox | https://paste.ubuntu.com/p/mCnQfD6StH/ | 00:33 |
| sarnold | heh :/ | 00:33 |
| xnox | i think that's progress! | 00:33 |
| xnox | cause i get new errors =) | 00:33 |
| sarnold | hey! :) | 00:33 |
| xnox | "File name too long" lovely | 00:33 |
| sarnold | new errors are always great | 00:33 |
| xnox | stgraber, what insanity do i need to set on my snap.lxd.daemon.service to make it "production"? also, do you want to try installing corosync from eoan-proposed to make it start in the lxd container? at the moment, that fails for me =( | 00:34 |
| xnox | [pid 336] setsockopt(12, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4) = -1 EPERM (Operation not permitted) | 00:38 |
| xnox | hmmm | 00:38 |
| xnox | if (savederrno == EPERM) { | 00:45 |
| xnox | errno = ENAMETOOLONG; | 00:45 |
| xnox | kwalitee =) | 00:45 |
| sarnold | bingo | 00:45 |
| sarnold | systemd again? | 00:45 |
| sarnold | or apparmor this time? :) | 00:45 |
| xnox | nah, kronosnet-1.8 | 00:45 |
| xnox | but the eprm is real | 00:45 |
| xnox | i do not see things in apparmor denials.... | 00:46 |
| xnox | sarnold, i think it wants the real CAP_NET_ADMIN for no reason. | 00:52 |
| xnox | cause reading SO_RCVBUF & SO_RCVBUFFORCE in http://manpages.ubuntu.com/manpages/disco/en/man7/socket.7.html | 00:53 |
| sarnold | xnox: yeah it's really annoying that this cap is needed for something that feels so bland | 00:53 |
| xnox | it's normal that i can't do the later, but if the former succeeded... i fail to see why we force things?! | 00:53 |
| xnox | root@nice-mako:~# strace -s99999 -f /usr/sbin/corosync 2>&1 | grep setsock | 00:53 |
| xnox | [pid 386] setsockopt(12, SOL_SOCKET, SO_RCVBUF, [8388608], 4) = 0 | 00:53 |
| xnox | [pid 386] setsockopt(12, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4) = -1 EPERM (Operation not permitted) | 00:53 |
| sarnold | xnox: loads of apparmor profiles either have to decide to grant this terrifying priv, or force a failure here :( | 00:54 |
| xnox | ah, maybe it did fail! | 00:56 |
| xnox | [pid 401] setsockopt(12, SOL_SOCKET, SO_RCVBUF, [8388608], 4) = 0 | 00:56 |
| xnox | [pid 401] getsockopt(12, SOL_SOCKET, SO_RCVBUF, [425984], [4]) = 0 | 00:56 |
| xnox | [pid 401] setsockopt(12, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4) = -1 EPERM (Operation not permitted) | 00:56 |
| xnox | cause it's trying to set 8388608, but gets back 425984 instead. smells like one more "ulimit" imposed on me. | 00:56 |
| xnox | and calling it a night. | 00:57 |
| xnox | exit | 00:57 |
| sarnold | this one might be a cgroup for kmem or similar? you wouldn't be happy if your fart app container went crazy and allocated half your kernel memory in silly receive and send buffers.. | 00:57 |
| sarnold | gnight xnox ;) | 00:57 |
| === ricab is now known as ricab|bbl | ||
| LocutusOfBorg | mdeslaur, FYI, I syncd libcaca, discarding your doxygen-latex switch, basically because the fix is now probably in doxygen, and the package doesn't FTBFS anymore https://launchpad.net/ubuntu/+source/libcaca/0.99.beta19-2ubuntu2 | 09:25 |
| LocutusOfBorg | https://launchpad.net/ubuntu/+source/libcaca/0.99.beta19-2.1 | 09:25 |
| mwhudson | rbasak: does the git source package importer have some magic way of getting things out of the debian NEW queue? | 09:37 |
| mwhudson | (it seems unlikely but i thought i'd ask) | 09:38 |
| mwhudson | oh wait you can't even download stuff from new | 09:41 |
| rbasak | mwhudson: yeah, sorry. I was going to say wishlist but you've reminded me it's impossible. | 09:58 |
| rbasak | mwhudson: you might find git/bin/git-dsc-commit in the source tree useful. If you have a source package you can "force commit" it into a branch. Eg. an orphan branch. Then you can at least diff it against other things, etc. | 09:59 |
| TomyWork | hi | 10:05 |
| TomyWork | I'm trying to install ibm notes (formerly known as lotus notes) from the vendor's .debs. It's a 32 bit package that depends on gdb. This has always been a problem, since I'm on a 64 bit system and I have a 64 bit gdb package. On 14.04, I used an otherwise empty package with this control file in order to get it to work: https://paste.ubuntu.com/p/wKRXyfzFk3/ On 18.04, when trying to install that package, I now get a conflict: https://paste.ubuntu | 10:05 |
| TomyWork | .com/p/GRXHwrBzPG/ this is likely due to the fact that the 18.04 gdb:amd64 package conflicts with "gdb", which the 14.04 gdb:amd64 package did not. How do I install a package that requires gdb:i386 while that gdb:amd64 package is installed and conflicting with any other package that even *provides* "gdb" | 10:05 |
| TomyWork | oops, that link got cut in half. here's the whole link: https://paste.ubuntu.com/p/GRXHwrBzPG/ | 10:06 |
| juliank | ugh I merged wpa from experimental but wrote unstable in the changelog, sorry | 10:06 |
| juliank | I merged unstable first, then copied changelog over and forgot to replace it :D | 10:07 |
| === ricab|bbl is now known as ricab | ||
| marcustomlinson | sil2100: hey! any chance you got around to https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1826560 | 10:53 |
| ubottu | Launchpad bug 1826560 in libreoffice-l10n (Ubuntu Disco) "[SRU] libreoffice 6.2.3 for disco" [High,In progress] | 10:53 |
| mdeslaur | LocutusOfBorg: cool, thanks! | 10:59 |
| mwhudson | rbasak: ah yeah that might be handy indeed | 11:28 |
| mwhudson | rbasak: i can probably get the uploader to give me the dsc | 11:28 |
| mwhudson | (or just make one from git) | 11:28 |
| rbasak | mwhudson: if it's already in git, then surely you already have it in git? :-) | 11:44 |
| === ricab is now known as ricab|lunch | ||
| xnox | sarnold, | 12:40 |
| xnox | sudo sysctl -w net.core.wmem_max=8388608 | 12:40 |
| xnox | sudo sysctl -w net.core.rmem_max=8388608 | 12:40 |
| xnox | was the answer to the other one, and i do have corosync/pacemaker in the container now. Opened: https://bugs.launchpad.net/auto-package-testing/+bug/1828228 | 12:40 |
| ubottu | Launchpad bug 1828228 in Auto Package Testing "corosync fails to start in container (armhf) bump some limits" [Undecided,New] | 12:40 |
| === ricab|lunch is now known as ricab | ||
| === Wryhder is now known as Lucas_Gray | ||
| rbasak | ahasenack: on bug 1616123, did we already make a decision to SRU it? I remember something like bug - is this the only instance or was there another variable affected in another bug? | 14:02 |
| ubottu | bug 1616123 in nfs-utils (Ubuntu Cosmic) "rpc-svcgssd.service uses incorrrect variable SVCGSSDARGS" [Undecided,In progress] https://launchpad.net/bugs/1616123 | 14:02 |
| ahasenack | rbasak: we will want to sru it, we were waiting on what debian was going to do, but they made the same change | 14:02 |
| rbasak | ahasenack: I'm wondering from the perspective of "is this worth an SRU?" | 14:02 |
| rbasak | Because a workaround is to override via systemd in /etc, right? | 14:02 |
| ahasenack | it's a low hanging fruit | 14:02 |
| ahasenack | yes | 14:02 |
| rbasak | OK | 14:03 |
| ahasenack | a good one for someone new perhaps? :) | 14:03 |
| michael-vb | Hello, does anyone here feel responsible for the update-secure-boot-policy script in shim-signed? It is intended to be used by DKMS modules, but I have experimental changes to the VirtualBox installer to use it as well, and wanted to talk about that. | 14:35 |
| michael-vb | I e-mailed Mathieu Trudel-Lapierre, who is in various change logs, but didn't get a response. | 14:36 |
| xnox | michael-vb, well, talk about it. how are you using it? | 14:46 |
| michael-vb | Well, the bit in my script I like the least is this: | 14:48 |
| michael-vb | # update-secureboot-policy "expects" DKMS modules. Work around this and talk to the authors as soon as possible to fix it. | 14:48 |
| michael-vb | mkdir -p /var/lib/dkms/vbox-temp | 14:48 |
| michael-vb | update-secureboot-policy --enroll-key 2>/dev/null || [...] | 14:48 |
| michael-vb | rmdir -p /var/lib/dkms/vbox-temp 2>/dev/null | 14:48 |
| michael-vb | If you see what I mean. | 14:48 |
| michael-vb | At this point that will have to stay in my script so that it works with existing versions of update-secureboot-policy, but it would be great if it were not needed. | 14:50 |
| michael-vb | And the other thing was whether there were any thoughts about a cross-distribution solution, say with the freedesktop/XDG people. I would assume that | 14:53 |
| michael-vb | they would want to see a bit more protection of the private key, like | 14:53 |
| michael-vb | optionally adding a protection password (if that is possible), or | 14:53 |
| michael-vb | letting the user specify the location at signing time and optionally | 14:53 |
| michael-vb | mounting external storage containing the key. | 14:53 |
| michael-vb | (Sorry, pasted that from an e-mail which was of course line-split.) | 14:54 |
| xnox | michael-vb, no passwords is an Ubuntu UX decision. | 14:55 |
| xnox | michael-vb, so even if passwords / unlocking / tpm / usb-stick is added, we'd need/want to keep "unprotected/passwordless/unattended" mode as well. | 14:56 |
| xnox | michael-vb, re bogus directories to enroll-key => please open a bug report and propose a patch? to either just do things, or do things if there is like '--force' or something? | 14:56 |
| michael-vb | Happy to do that (the bug report). | 14:57 |
| xnox | michael-vb, and well do wait for response from cyphermox cause i think he does maintain that script. and we do keep changing what we do by default, and etc. | 14:57 |
| michael-vb | I just wanted to talk to someone first to get your thoughts. | 14:58 |
| michael-vb | Like if someone was going to say "no way, this is only for DKMS". | 14:58 |
| cyphermox | michael-vb: I have been writing that email response to you, I just want to get it just right | 14:59 |
| cyphermox | michael-vb: essentially, you probably don't want to use update-secureboot-policy; it's not needed for what you want aside maybe to create the key to begin with | 15:01 |
| cyphermox | for everything else it's just a wrapper, so if you don't want to use DKMS, you might as well just call mokutil --import yourself if needed, and sign things yourself using kmodsign | 15:01 |
| cyphermox | for anything else, I mean, sure, protecting the key more is possible, but it's not necessarily going to do much aside from making it more hoops for users to jump through to get something signed, even if it's automated | 15:03 |
| michael-vb | There were two reasons I was keen to use update-secureboot-policy. One was that I don't want to replicate all the debconf bits but still get a native "experience". And the second is more evil, if I do it myself I am responsible for the security decisions. | 15:03 |
| michael-vb | Those added hoops are what I imaging other distributions might want to see, not what I am interested in myself. | 15:04 |
| cyphermox | well, you can also call update-secureboot-policy --enroll-key as part of your build it will do the password asking | 15:04 |
| michael-vb | Right, so then the question is - can you remove that "if [ $dkms_modules -lt 2 ]; then" part? | 15:06 |
| michael-vb | Working around it for existing deployments of the script is no problem, I just feel better when I am not fighting against the tools I am using. | 15:06 |
| cyphermox | not really | 15:06 |
| cyphermox | this is specifically so upgrades happen seemlessly without prompting the user again | 15:06 |
| michael-vb | Could you add a couple of words to that? | 15:07 |
| cyphermox | if you don't have a key enrolled and already had a dkms module installed, you don't necessarily want to prompt to enroll again unless a new DKMS module appears | 15:09 |
| michael-vb | Oh, I thought that that line would detect any DKMS modules, not just new ones. | 15:10 |
| LocutusOfBorg | seb128, can I abuse your patience once more and see if you can help me in xpdf poppler sadness? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3714/+packages its the last one | 15:12 |
| seb128 | LocutusOfBorg, hey, not today but I can have a look tomorrow | 15:12 |
| LocutusOfBorg | basically I have to replace goolist with std::vector, but my c++foo sucks :) | 15:15 |
| LocutusOfBorg | I'll try again tonight | 15:15 |
| michael-vb | cyphermox: have to go for a bit (will stay in the channel), but actually what I would like would be a way of using update-secureboot-policy without having the feeling that I am using it in a way I should not be. So removing that line was an idea, but any other way to say "please continue even though no DKMS modules are there" is fine too. | 15:20 |
| michael-vb | An environment variable would be nicer than a switch of course, as the switch would break on current versions. | 15:21 |
| michael-vb | Oh, actually "sudo /usr/sbin/update-secureboot-policy --enroll-key --foo" works without complaining. | 15:22 |
| michael-vb | Forget the environment variable thing then. | 15:22 |
| michael-vb | Back later. | 15:22 |
| cyphermox | yup | 15:23 |
| michael-vb | (Why does everyone in software love the word "foo" so much?) | 15:23 |
| ginggs | fooknows | 15:27 |
| michael-vb | cyphermox: oh yes, the other thing - did you have any ideas of co-operating with other distributions about handling this at some point, or is that something you are not interested in starting? If the second I would ping Hans again myself to ask who to talk to. | 15:32 |
| michael-vb | Away again. | 15:32 |
| cyphermox | michael-vb: it's not about not being interested, tbh it's more that I'm not sure I currently have any time to put to that endeavor; and it really needs to work on desktop and servers equally well. | 15:33 |
| cyphermox | (so that means a gtk-only solution is out of the way, that's partly why debconf was a "good idea" for this) | 15:34 |
| cyphermox | essentially, that means some amounts of UI engineering work; it's not like a shell script that can be banged together in a couple of hours :) | 15:35 |
| michael-vb | I read that as I am welcome to ask people, but on my time. | 15:35 |
| cyphermox | michael-vb: I sent my response by email already; best is to file a wishlist bug and we can discuss that; maybe I can get time blocked to work on that | 15:36 |
| michael-vb | Thanks. | 15:36 |
| sarnold | xnox: nice, thanks | 16:39 |
| plongshot | Please forgive me if I've come to the wrong place but I'm not connecting with people in the regular channel and I don't know if it's because my question is a bit dense or what. Can anyone kindly advise on the best way to find what I need? | 17:11 |
| plongshot | My original qestion was thus.. | 17:11 |
| plongshot | I dont' know the connections under the hood with ubuntu but is the location for the default directory for bluetooth file transers determined by something else in the system? In other words, is it going off of some default setting for "Downloads" folder location and create the folder if ti down't exist? If that is so then maybe I should look for a way to change the setting for the defalult "Downloads" location and the things | 17:11 |
| plongshot | the rely on it will honor that? | 17:11 |
| plongshot | ty | 17:11 |
| plongshot | I need to seriously mitigate mutations to my directory structure - It drives me nutz! :> | 17:13 |
| plongshot | I'm on / talking about 18.04 | 17:14 |
| === SuperKaramba is now known as BenderRodriguez | ||
| mwhudson | rbasak: you make a good point | 21:24 |
| === msmarcal is now known as msmarcal|eod | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!