=== chris14_ is now known as chris14 [01:23] does anyone in prod really want their server to dhcp on all interfaces by default? [01:27] mybalzitch, no, i would do static in router [01:27] one beyond dhcp. [01:27] dhcp 1-128, server 129 [01:28] no standard ports, 22, and such [01:29] * oerheks checking state of fail2ban === BarnabasDK_ is now known as BarnabasDK [13:21] ahasenack: can you give me at least the current git repo for samba in ubuntu? I've some spare minutes so I can get some stuff merged.. [13:22] mjt0k: https://code.launchpad.net/ubuntu/+source/samba [13:22] but it's down atm [13:22] big outage going on [13:22] status.canonical.com [13:22] oh ok [13:22] I'm just in time, it looks like :) [13:22] the branches are: ubuntu/devel -> tip (oracular, currently) [13:22] ubuntu/-devel: tip of that release (for example, ubuntu/jammy-devel) [13:24] is it the same for qemu? [13:24] the repo and layout that is [13:24] being down? Yes [13:24] branch structure? Yes [13:24] qemu git repo would be https://code.launchpad.net/ubuntu/+source/qemu [13:25] got it, thanks! [13:25] that's the web ui, the git clone argument would be... [13:25] pkg https://git.launchpad.net/ubuntu/+source/qemu (fetch) [13:25] pkg ssh://@git.launchpad.net/ubuntu/+source/qemu (push) [13:27] I plan, for samba, to eliminate samba-vfs-modules (it makes no sense), and due to gluster, the extra package with the gluster module will stay. It'd be nice to name it samba-vfs-gluster perhaps, but I'm not sure for this (since ubuntu already has -modules-supplemental) [13:27] I thought perhaps other modules in the future would join gluster, but I don't mind renaming [13:28] and for qemu, either qemu-block-gluster or qemu-block-extra-extra (whatever it was, I forgot) [13:28] qemu-block-extra existed, I added qemu-block-supplemental [13:28] yeah [13:29] rh ships each module in its own package, fwiw [13:29] but I'd love something in-between :) [13:29] as long as there is a meta package pulling them back together, that would also work [13:31] ok. It'd be nice still if you had something which I can merge in one way or another. Maybe just a list of commits which should be picked up, so I'll not study them all one by one [13:31] let's see [13:31] like, eg, 980381b3331f1e7895725ce80de53e410c638b29 for qemu [13:31] we try to keep the delta tidy [13:32] hmm. this commit disables vnc for microvm.. [13:33] mjt0k: this one for qemu? https://paste.debian.net/1320894/ [13:34] yes, that's the one in question, - either keep it this way or rename it to -gluster [13:35] I can just pick it up (hopefully it wont break debian) [13:35] in samba it's 3: https://paste.debian.net/1320895/ [13:35] is that all?? I thought there's much more.. [13:35] heh [13:35] gluster had delta before because of i386 [13:35] but I think you have that one too now [13:36] yup [13:37] ok. that makes sense. I'll just merge that stuff for samba (plus some logic to d/rules) and for qemu [13:37] thanks! [13:38] awesome [13:41] btw, is there an "ubuntu" build profile? [13:42] so that the same source can be built on both debian and ubuntu but with different build-deps [13:42] and maybe with different set of packages [13:42] I don't think there is [13:42] qemu has some smarts in d/control-in, but it's not a build profile [13:43] these smarts exists exactly *because* there's no such profile, I'd say :) [13:43] heh [14:52] in the login banner, what temperature is it referencing [14:56] mybalzitch: "the temperature reported in MOTD is the highest temperature of all thermal zones reported by Sysfs API, at login" was the answer aonth ago [14:57] oh thanks [15:42] ahasenack: 980381b3331f1e7895725ce8 (qemu) is needed too, right? Can you tell me why vnc has been disabled? It was explicitly asked feature in debian.. [15:43] just a sec, in a call [15:44] mjt0k: that one I don't know about, or remember. sergiodj? [15:44] I can't reach LP#2045594 now either :) [15:45] :/ [15:46] btw, for qemu, I can pick up ubuntu-specific machine types change too, - I see no reason why not. Maybe it's more difficult for you to update the patch this way, though [15:47] mjt0k: sergiodj is maintaining qemu nowadays, I don't know how hard that delta is to maintain [15:47] should be pretty easy (±d/patches/series clashes) [15:48] yeah, that's fine [16:45] (meeting) [18:10] sergiodj: new qemu (in qemu-block-extra too) also ships block-blkio, with libblkio written in rust [18:11] sergiodj: I guess this one should go to -supplemental in ubuntu too [18:12] oh, we're already seeing rust creeping into qemu as well? [18:12] heh [18:12] mjt0k: thanks for the heads up [18:12] not yet [18:13] libblkio is written in rust, but it provides an .so (libblkio.so) which is used as a regular shared lib from C code in qemu [18:13] got it [18:13] but there are multiple attempts already to provide parts of qemu itself in rust [18:14] including rewriting some already existing pieces [18:14] I had hard time packaging libblkio for debian [18:14] yeah, not surprised [18:15] so, about the whole -supplemental thing, do you have another approach in mind for the problem? [18:15] I just kept your package name for now [18:15] OK, fair [18:17] since I re-did saving modules on upgrades while you introduced the new package, I updated the saving procedure now to handle multiple packages. it becomes a bit more complicated but it is now generic, can be used for any modules [18:18] doing a test build now, will push the commits shortly [18:20] *sigh*. list=$(ls -1 ...); cat < | xargs? [18:23] or just $(echo ${list}) inside the cat [18:23] yeah [18:26] extra indirection :) [20:06] sergiodj: see top 3 commits in salsa:debian/master [20:11] mjt0k: thanks! without having tested it, it looks good [20:12] btw, you were also asking about the reason for removing a few features from microvm. that came up during an internal discussion with cpaelzer, where we decided that those features were either not useful in a microvm scenario, or introduced attack surfaces without much benefits [20:13] sergiodj: "some features" = vnc [20:13] it was also done as part of our efforts to consolidate the qemu configurations that we (Ubuntu) and LXD used. as part of that effort, LXD has now been using our qemu instead of compiling their own [20:14] mjt0k: right, vnc fell under the "attack surface" category [20:14] bear in mind that that's only for microvm [20:14] sure [20:14] I had a bug in debian asking to enable vnc for microvm [20:14] oh? [20:14] iirc anyway [20:14] recent bug? [20:14] no [20:15] fair. btw, we can revisit the list of disabled/enabled features, it's no big deal [20:15] on the one hand I was happy to see a smaller attack surface, but OTOH I was not happy to see our delta grow :-/ [20:16] apparently I'm wrong. --enable-vnc was there since microvm is created [20:16] aha [20:18] which display microvm uses anyway? [20:18] 3962d7f612cbd9205718856c964ca5e74d122ce7: d/rules: enable vnc for microvm build [20:19] (aug 2021) [20:19] aha. Now I remember. It was me who didn't know how to test microvm without display [20:20] ah, that's fair :) [20:21] so, how to use it? [20:22] we have some documentation here: https://ubuntu.com/server/docs/using-qemu-for-microvms [20:22] what good --enable-pixman is for, without vnc? [20:24] that doc is outdated (wrt the package name and the name of the binary) [20:24] and, do not run qemu with sudo [20:25] heh [20:25] yeah, we're going over some of our outdated docs [20:26] -display curses makes no sense with -nographic [20:27] isn't -nographic alone enough? [20:28] actually I don't remember anymore (I did a few tweaks to -nographics already, it's one of the uglier options of qemu) [20:29] I mean, -nographic redirects many things, but I don't remember if it's possible to have a display after it [20:30] let me try here [20:32] qdict_put_str(machine_opts_dict, "graphics", "off"); [20:35] sergiodj: let's move to #debian-qemu @oftc so not to hijack #ubuntu-server :) [20:35] sure [20:35] (though I dont have much time for all this already :)) [20:36] me neither, TBH