[04:40] hi all [04:40] i want create a sftp server with ubuntu 18.04 [04:41] i have a second hard and i want user save file in this hard not /home/username directory [04:41] how i can do this ? [06:11] Good morning === cpaelzer__ is now known as cpaelzer [08:16] jamespage: coreycb: we are seeing a regression of https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1790598 on neutron 2:12.0.6-0ubuntu2 on xenial [08:16] Launchpad bug 1790598 in neutron (Ubuntu Xenial) "metadata service calls to nova-api-metadata with IP based SAN's fails" [Low,Triaged] [08:17] the reason seems to be that https://review.opendev.org/599541 was removed from debian/patches, but it got merge upstream only into 12.1.0, not in 12.0.6. also doesn't seem to affect bionic due to newer python libs probably === Wryhder is now known as Lucas_Gray [12:02] frickler: indeed it was - sahid ^^ [12:03] sahid: metadata-use-requests-for-comms-with-nova-api.patch was not included in the upstream release for 12.0.6 [12:03] so we'll need to re-instate that patch OR superceed quickly with 12.1.0 [12:04] coreycb: fyi ^^ [12:16] jamespage: i'm rebasing stable/queens to 12.1.0 right now [12:23] good morning o/ [12:26] 👋 [12:50] hi everyone, i'm looking for a "guideline" for building a custom webserver (nginx + php). my doubts are about how to best configure service users, using or not www-data, how to best configure folders, log path, etc... for separating different website. i'm in a protected environment (not commercial hosting) so my users are mainly developers of the c [12:50] ompany, so a classic shared webserver for different application :) any help apreciated [13:12] Hi, folks. [13:12] I like the containerized + haproxy setup for websites. Each website has its own container, haproxy figures out what traffic to send where. [13:12] Who can help make this small change to the edk2 package: https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1836859 [13:12] Launchpad bug 1836859 in edk2 (Ubuntu) "RFE: Ship the firmware "descriptor files" as part of the 'ovmf' package" [Undecided,New] [13:12] The current maintainer seems to be away on PTO. [13:13] And I don't know Ubuntu enough to 'query' for other maintainers. (I come from Fedora land :-)) [13:13] It requires someone vaguely familiar with QEMU (and EDK2/OVMF). [13:19] coreycb, jamespage: https://git.launchpad.net/~sahid-ferdjaoui/ubuntu/+source/neutron/log/?h=stable/queens [13:19] sahid: on it [13:19] coreycb: buildroot: https://launchpad.net/~sahid-ferdjaoui/+archive/ubuntu/bionic-queens/+build/17334854 [13:20] also i had to remove two patches which were already included: https://pastebin.ubuntu.com/p/TCP78jC2tK/ [13:21] kashyap: IMHO we have time to wait for dannf [13:21] kashyap: this is a feature tied qemu 4.1 which means Ubuntu 20.04 [13:21] I tihnk rushing something into edk2 now will gain us nothing but probably problems [13:22] cpaelzer: Hmm. I'm coming here and pestering because I'll be away on PTO (from 06-Aug to 23-Aug). And Nova could use it [13:22] kashyap: but could it use it without any related commit in qemu? [13:22] cpaelzer: Note that is not strictly tied to QEMU 4.1 -- you can still use them with older QEMU versions. [13:22] I haven't checked the details, only have seen that it came with 4.1 (in the bundled rom release) [13:22] cpaelzer: If you have libvirt 5.3 or above, then you can use them with older QEMU [13:23] kashyap: can one "benefit" from it without qemu 4.1 [13:23] we are on libvirt 5.4 already [13:23] and I have talked with Dannf before his PTO [13:23] cpaelzer: Good question :-) I'm doing this to be able to test Nova's Secure Boot spec in the OpenStack Gate: http://specs.openstack.org/openstack/nova-specs/specs/train/approved/allow-secure-boot-for-qemu-kvm-guests.html [13:24] cpaelzer: If you see the JSON files: they simply describe the features of the EDK2 binaries that you ship in Ubuntu. [13:25] yeah [13:25] but doesn't that mean that you can already test it right now manually? [13:25] cpaelzer: libvirt 5.3 or above will read them, and then will auto-add the relevant bits if you want Secure Boot [13:25] by dropping matching json files in place (manually) and see if things work [13:25] if they do add it to the bug which will help dannf to ensure what is placed will be the correct content [13:25] cpaelzer: Oh, sure. But just trying to set things in motion while I still have the motivation :-) [13:26] I absolutely appreciate that part of it :-) [13:26] and I now undertsnad why you are in a hurry (your PTO timing) [13:27] in motion things are already, since we both reached dannf and he acknoledged to do it after he is back [13:27] cpaelzer: As we speak, I'm harassing the QEMU packager on #qemu, asking what he meant in his comment at the end of a similar request: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932269 [13:27] Debian bug 932269 in ovmf "Ship the firmware "descriptor files" as part of the 'ovmf' package" [Normal,Open] [13:27] cpaelzer: Hehe, sorry, I should've made my motivation clearer. [13:28] cpaelzer: Okido. Just wanted to check in here, as things tend to fall through the cracks, as everyone is busy :-) [13:28] kashyap: this is a curcular dependencyas dannf is the maintainer [13:28] mjt as well, but he is more the qemu than the edk2 maintainer (usually) [13:29] Right, I just asked 'mjt' on #qemu. Will check later [13:29] cpaelzer: Also, I hope Ubuntu is now shipping a "variables files" (VARS) with default UEFI keys (from MS) installed [13:30] kashyap: /usr/share/OVMF/OVMF_VARS.ms.fd [13:30] If you're not aware; disregard my remark -- that's a detail 'dannf' knows -- I described to him a few weeks ago on #debian-qemu (on OFTC) [13:31] cpaelzer: Ah-ha, the 'ms' is presumable with MS keys. It can't be anything else [13:31] Last I checked I knew that Ubuntu was shipping the script we wrote to enroll the MS keys. (Noticed in the tarball here: https://launchpad.net/ubuntu/+source/edk2/0~20190309.89910a39-1ubuntu1) [13:32] So all good there. [13:32] kashyap: this was from 0~20190606.20d2e5a1-1ubuntu2 [13:32] kashyap: give your test a try by manually placing the json files [13:32] cpaelzer: Noted, on the version. [13:33] kashyap: and if it works with the libvirt 5.4 that is in Eoan (maybe with modifications to the json files) update the bug on edk2 to let dannf know that this makes sense for Eoan [13:33] he might (as I was) assume that this is only needed in 20.04 [13:33] cpaelzer: But ... note that: simply dropping in there doesn't _quite_ fly: as I don't know (unless I look in the code) if Ubuntu's EDK2 build differs in anyway than Fedora (the I'm familiar with) [13:33] the only differens seem to be paths right? [13:34] Because based on that you (the "mythical you") need to add or remove some lines from the "features" bit. [13:34] cpaelzer: That's what I'd expect, frankly [13:34] For example, see for Fedora, the "features' its EDK2's MS-signed binary (called: OVMF_CODE.secboot.fd) has are these: [13:34] + "features": [ [13:34] + "acpi-s3", [13:35] + "enrolled-keys", [13:35] + "requires-smm", [13:35] + "secure-boot", [13:35] + "verbose-dynamic" [13:35] --- [13:35] Now I don't know if they match 1-1 in Ubuntu. 97.83% yes, they _should_ match. [13:36] kashyap: which would be perfect to be outlined on the bug [13:36] even if you make assumptions you can provide this example from fedora and the link to the openstack usage of the feature and the result of your testing [13:36] I'm sure dannf will prefer to change a few features than to blindly guess adding something totally untested [13:37] Right, will do. Once I replenish my "yak trimming" quota :-) [13:37] hehe [13:37] kashyap: just trying to guide you to the progress that you poked this channel for :-) [13:38] Certainly; just joking, as you know. Much appreciated. [13:38] sure, np [13:52] sahid: i think we should just add back the missing patch(es) for now and the SRU team will be more likely to fast-path this into -updates [13:52] sahid: and then we can do a 14.1.0 after that [13:53] sahid: s/14/12/ [13:55] coreycb: based on jamespage comments both ways were OK. can you taking care of adding that patch? I'm still with the horizon thing and i would like make progress [13:57] sahid: ok i think i'll just do 2:12.0.6-0ubuntu3 for now with the patches added back then. sorry i think it'll just be easier to convince them to fast track it this way. how's horizon? [13:59] coreycb: yes that makes sense, just question, in all cases they will ask for a complete tests, no? [14:00] sahid: that's a good question which is frustrating in this case. perhaps frickler can help us verify the fix. [14:01] sahid: frickler: fyi https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1838263 [14:01] Launchpad bug 1838263 in neutron (Ubuntu) "neutron 2:12.0.6-0ubuntu1 queens regression" [Undecided,New] [14:01] coreycb: if we have to provide a complete test i think we should fo with 12.1.0 [14:02] sahid: that's a valid point. frickler any chance you'll be able to help with verifying a new version of neutron to verify the queens regression is fixed? [14:06] coreycb: I agree that going forward with 12.1.0 is the better solution, I can test new pkgs once you build them. [14:07] frickler: if we want to get a fix out ASAP i think we just need to add the patches back for now [14:08] coreycb: well we did fix things locally, so for me this isn't urgent [14:09] coreycb: but I could test that variant too, of course [14:10] frickler: thanks, that would be very helpful [14:10] frickler: and we'll get 12.1.0 out right after this [14:18] coreycb: I'm lost I thought the outcome of the discusion with frickler what to move forward and only provide a new version based on 12.1.0, no? [14:19] s/what/was [14:19] sahid: we'll just add the single patch back and fast path that through with testing from frickler. and then we'll follow that with a 12.1.0 that we'll test ourselves. [14:20] sahid: less chances of further regressions that way [14:29] hi...I'm creating a cron job but I think I'm getting into problems with wildcards (find -type f -name '*.tar.gz' -mtime +2 -exec rm {} \;) [14:30] is there an alternative to this? [14:40] m_tadeu: not if you don't say what the 'problems with wildcards' are [14:40] m_tadeu, what exactly goes wrong? [14:43] tomreyn, lordcirth: pbcak :P [17:33] Hello I have a question about bridging connections [17:33] is this the right place for my question or should I search for another channel? [17:34] I want to bridge my router to a router in another contry [17:34] ncuxo: be sure to actually *ask* a question :) [17:35] :) just did I was trying to go as basic as possible :D [17:35] ncuxo, if you are configuring this networking setup on Ubuntu, yes, you can ask here. [17:36] well to be honest I have no Idea how to configure it [17:36] I want to tunnel to the other router [17:37] all the traffic to be encrypted [17:37] In my mind it is something like a private vpn tunnel [17:37] ncuxo, such that both networks appear to be directly connected? [17:38] yes and I want my ISP to be unable to see my traffic [17:38] bought ISP's [17:38] I believe that would be called a "site-to-site VPN" [17:39] ncuxo, try this? https://sysadmins.co.za/setup-a-site-to-site-ipsec-vpn-with-strongswan-on-ubuntu/ [17:39] ncuxo: do you know why you want a bridge? are you specifically looking for a layer-2 vpn? [17:40] sarnold: I want the government in the country that I'm residing not to be able to check my traffic [17:41] ncuxo: aha cool; lordcirth's link looks like a good starting point to me [17:42] ncuxo: ubuntu also supports openvpn, https://help.ubuntu.com/lts/serverguide/openvpn.html [17:43] openvpn is very flexible and compatible with many tools, but can be fiddly to configure. This Strongswan seems specifically made for this sort of thing. [17:43] I should try it sometime myself [17:43] hmm but with this I will need a full os on the receiving end ? [17:44] ncuxo, yeah, Ubuntu on both ends. Is that not an option? [17:44] many routers will support either openvpn or ipsec out of the box [17:44] lordcirth: thx for the tutorial I'll check it later today [17:45] Yeah. Although, doing all the encryption on a low-end router could have poor performance. [17:45] ncuxo, let us know how it went! [17:51] lordcirth: if I use a pfsense firewall router on a dell r710 server with kvm ubuntu virtualisation [17:52] should this be a sufficient encryption standard on the connection? [17:53] okay brb wife calling for dinner [17:57] ncuxo, I don't see how any of that determines the encryption [18:00] r710 looks to be xeon 5500 and 5600 series [18:03] some of those have aesni but I can't find throughput numbers [18:04] finally something with some numbers: https://blog.scottlowe.org/2012/09/12/clds006-exploring-new-xeon-e5-optimizations-for-10-gb-ethernet/ ""throughput increased from 5.3 Gbps at ~91% CPU utilization with a Xeon 5500 (no AES-NI) to 33.3 Gpbs at ~79% CPU utilization on an E5-2600 with AES-NI support" [18:27] aes-ni support is funny also [18:28] you have to bulk encrypt to get good numbers, generally packet sized doesn't do well [18:28] wonder if you get full 64k packet offloading aes-ni support [18:28] plus doing it in a vm adds extra cpu context changes, your milage will vary :) [18:29] just don't use openvpn [18:29] openvpn is still single core bound [18:30] I was maxing out at 300mbit [18:30] next time I attempt that, I'll get a desktop cpu with like 4ghz clock speed [18:37] patdk-lap: hmm, now I realize that I don't know well enough how these things work -- does the application need to resubmit the key to the aesni instructions every packet? [18:40] I dunno how linux does it [18:40] I know when they where working on it for illumos, they tested it, and it's just the amount of setup overheat is restrictive [18:40] unless you do so many operations at a time [18:43] I think the same goes for all those advanced features, floatingpoint, mme, ... [18:43] just takes so much time to transfer the instructions and data to the unit to process, once it is going it's fast though [18:43] so doing small amounts of data can be a real overhead due to setup costs [18:44] yeah floatingpoint / mmx stuff .. if it's used in a process, then that state needs to be cleared and reset across context switches, so if you're going to use it, you better *use* it :) but I realize I don't know how aesni works. heh. [18:45] I can't seem to locate it, was a blog post someone posted in development [18:45] was a few years ago [18:45] few == 5+? [18:46] dang; thanks for looking [18:46] * patdk-lap blames rss feeds [18:46] easy to read and remember [18:46] hard to relocate [18:47] heh then maybe it was a bit more than five years ago? :) [18:47] cannot be before 2012 [18:48] as I'm possitive it was illumos related, and I didn't start playing with it till 2011, and not working and reading about the kernel till 2013 or so [18:48] oh, aes-ni didn't exist till 2010 [18:49] also, issue with blogs, they vanish so quickly [18:50] if you're really lucky the old content just bitrots on an old ignored site.. [18:52] http://zfs-create.blogspot.com/2014/05/optimizing-illumos-kernel-crypto.html [18:52] I think that was it [18:52] patdk-lap: thanks :D [18:55] hahah "(luckily the GCM algorithm is limited to 64GB of data per key, so at least there is an upper bound to this nonsense)" [19:07] damn [19:07] I was right on with my 5year guess [19:07] :D [20:57] frickler: fyi the new neutron package version is availlable in bionic-proposed 2:12.0.6-0ubuntu3 === lborda is now known as lborda_afk [22:47] Hmmm. How would I rename a network interface that seems to decide on a new MAC address every boot? Tried setting a udev rule based on the vendor and model but either I'm doing it wrong or that won't work either (on 19.04). [22:48] (Normally I'd just create a systemd .link file, but I think that needs to be MAC based?) [23:01] keithzg[m]: https://netplan.io/reference#common-properties-for-physical-device-types gives you some options [23:01] keithzg[m]: based on bus location or driver name [23:02] (assuming the default name is based on bus location, which is the default I think) [23:06] rbasak: Hmm. I suppose that could work as long as I keep it plugged into the same USB port all the time; the driver name won't work then though since I believe I'm using NetworkManager rather than networkd. [23:07] ...hmm. As far as it reads to me, matching on name is precluded then too. [23:08] So I guess I'm back to trying to make a udev rule work, if that's even still possible. [23:08] Get a proper NIC? :) [23:08] I don't see why an early enough udev rule wouldn't work [23:09] Yeah I'm pretty confused by that, but also too rusty dealing with udev rules to be sure how to debug it, so was hoping there was an easier way. Alas. [23:10] Oh, you might need to disable any future standard renaming udev rules though [23:12] https://lists.ubuntu.com/archives/ubuntu-devel/2015-May/038761.html is a good guide to what there was [23:21] Aha, if I run `udevadm --debug test` against the USB device in question, I see it run through the rules in order but it was skipping my rule I was trying to sneak in early, I had just foolishly created the file as /etc/udev/rules.d/10-network-rules instead of 10-network.rules, whoops. And then it complained "Invalid ACTION operation" for ACTION="add", because it should actually be ==. Classic PEBKAC ;) [23:28] (That didn't actually accomplish the task at hand, but yeah probably into needing to find and disable/override other preexisting renaming rules) [23:58] Still haven't figured it out. Sigh.