| law | hey all, is there a way to chroot bind9 under Ubuntu 16.04 LTS? | 02:14 |
|---|---|---|
| law | I'm running into this upstream Debian bug - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820974 | 02:14 |
| ubottu | Debian bug 820974 in bind9 "does not start chrooted, ENGINE_by_id failed (crypto failure)" [Serious,Fixed] | 02:14 |
| law | it seems to be fixed in Debian Unstable with 1:9.11.2+dfsg-5, but Ubuntu Xenial has 1:9.10.3.dfsg.P4-8ubuntu1.9 | 02:15 |
| blackflow | law: you can achieve the same effect with systemd's ProtectSystem directive. Bind also has a working AppArmor profile you can use additionally. | 02:19 |
| blackflow | in addition you can run it as non-root, giving it CAP_NET_BIND_SERVICE capability (needed to bind ports < 1000) for extra security | 02:22 |
| law | eeeexcellent, thank you | 02:23 |
| law | got any docs for setting bind up with ProtectSystem? | 02:23 |
| blackflow | it's not bind specific, but systemd specific. see systemd.exec(5) manpage | 02:24 |
| law | do I need to prep a chroot-like directory, or does systemd take care of all that for me? | 02:25 |
| blackflow | With ProtectSystem=strict, you run the service in a fs namespace which has the entire fs readonly. So you need to add ReadWritePaths, to allow bind to write the log and various cache and temporary files. | 02:25 |
| blackflow | iirc, it requires /var/run/named, which means if you set RuntimeDirectory=named, systemd will mount /run/named (symlinked from /var/run/named) as RW with ProtectSystem=strict | 02:26 |
| blackflow | I haven't yet got to hardening Bind like this, but I can give you my nginx service file, so you can adapt from it. | 02:26 |
| law | sounds like I can remove the '-t /var/bind9/chroot' option from /etc/default/bind9, then? | 02:26 |
| law | that'd be super, actually | 02:26 |
| blackflow | https://dpaste.de/wykH | 02:27 |
| blackflow | consult the systemd manpages for those directives you're not familiar with, they're explained quite well | 02:28 |
| blackflow | ah yes, /var/cache/bind, you'll need that for ReadWritePaths | 02:29 |
| law | schweet, thank you! | 02:33 |
| law | is there a way to verify ProtectSystems is working /active? | 04:21 |
| law | 'ReadWritePaths=/var/cache/bind,/var/run/named,/var/log/bind9' seems to at least let the daemon start | 04:21 |
| pankaj | Hello, please anyone reply. | 08:55 |
| * tomreyn replies | 08:55 | |
| pankaj | tomreyn: Hello | 08:55 |
| tomreyn | pankaj: Hello | 08:55 |
| tomreyn | !ask | pankaj | 08:55 |
| ubottu | pankaj: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience | 08:55 |
| tomreyn | pankaj: do you have a question then? | 08:58 |
| pankaj | tomreyn: I am just using irssi for first time so I was testing it. I have to do more with it. | 08:58 |
| pankaj | Just if you know about how to use irssi and more about some other important commands. | 08:58 |
| tomreyn | i see, not really an #ubuntu-server question, i guess | 08:59 |
| tomreyn | if you develop concrete questions on irssi and those other commands you deem important, you are welcome to /joion #ubuntu and ask them there (assuming they are ubuntu related). there should also be #irssi or ##irssi. | 09:01 |
| tomreyn | * /join #ubuntu | 09:01 |
| soahccc | My googlefu is failing me. What specifies which kernel a given release is going to use? We just got 2 new machines and after installation they end up with a different kernel than our other machines on xenial (4.4 vs 4.13). | 11:28 |
| blackflow | soahccc: https://wiki.ubuntu.com/Kernel/LTSEnablementStack | 11:30 |
| soahccc | blackflow: thanks :) that's it | 11:31 |
| blackflow | While on the subject of kernels, I'm really interested to know what kind of effort it is to maintain a Ubuntu kernel. 18.04 is opting for 4.15 which is not an LTS kernel, meaning after a few years stuff will have to be backported without any support from upstream. | 11:47 |
| blackflow | uh... months, not years. | 11:47 |
| TJ- | blackflow: I suspect the workload will be worse for 4.15 since we've got a lot of Spectre patches to come and backporting some may be very invasive, but generally, it's not too burdensome | 12:14 |
| blackflow | but why not 4.14. It would make so many things easier, and the next one is only 6 months later, for 18.10 and 18.04.1 | 12:17 |
| blackflow | I really don't understand the decision to go with 4.15. What is gained with not using LTS for LTS.... | 12:18 |
| mason | blackflow: How much overlap will there be between 4.15's LTS and 18.04's LTS? | 16:17 |
| mason | s/4.15/4.14/g | 16:17 |
| mason | Half a year. Hrm. | 16:18 |
| mason | Yeah, 4.14 would have been a bunch less work. | 16:18 |
| FingerlessGloves | Hi guys, I got a bridge setup in my /etc/network/interfaces , it wont come up at boot have to do ifup | 16:46 |
| FingerlessGloves | Any idea why? | 16:46 |
| jelly | blackflow: upstream won't support 4.14 for very long really, often longterm are 2-3 years but a distro with a 5 year LTS has to do all the work from that point on and figure out all the security issues that upstream forgot to backport as well | 16:49 |
| jelly | FingerlessGloves: care to show your interfaces to see if there's anything obvious? | 16:51 |
| FingerlessGloves | https://paste.ubuntu.com/26385784/ | 16:51 |
| FingerlessGloves | surely the auto makes it come up at boot? | 16:51 |
| ChmEarl | a private bridge needs a static config | 16:54 |
| ChmEarl | yours says manual, not dhcp or static | 16:55 |
| FingerlessGloves | https://paste.ubuntu.com/26385945/ | 16:55 |
| FingerlessGloves | tried that too | 16:55 |
| jelly | manual is "here are some up and down command lines", sadly there's no syntax checker to stop you from doing what you did | 16:56 |
| FingerlessGloves | hmm still no luck when its set to static. | 16:57 |
| jelly | does the boot log say anything | 16:57 |
| FingerlessGloves | https://paste.ubuntu.com/26385978/ | 17:00 |
| FingerlessGloves | changed interface name to br_vianet | 17:00 |
| FingerlessGloves | just so you know | 17:00 |
| jelly | line 15 onwards is last reboot? | 17:01 |
| FingerlessGloves | yeah | 17:01 |
| FingerlessGloves | should of done dmesg instead of syslog | 17:02 |
| jelly | it _looks_ like it's up | 17:02 |
| FingerlessGloves | yet ip a, says it not | 17:02 |
| jelly | what does "brctl show" say? | 17:02 |
| jelly | and "ip a" or "ip l" | 17:03 |
| FingerlessGloves | no bridges expect the one lxc creates lxcbr0 | 17:03 |
| FingerlessGloves | ip l , doesnt show it either. | 17:03 |
| === dtscode is now known as nchambers | ||
| FingerlessGloves | /run/network/ifstate.br_vianet doesnt exist. | 17:16 |
| FingerlessGloves | so could something be bring down the interface? | 17:16 |
| blackflow | jelly: 2-3 years is still better than months. | 17:50 |
| jelly | blackflow: I suspect distro people have to track security and stability issues on their own anyway, so it's not as much extra work as one might expect | 17:52 |
| jelly | I mean Canonical is already supporting what, 3.13, 3.16 (this one they share with Debian), 4.4 (WAS upstream longterm, is not any more), 4.9?, 4.13, so what's one more? | 17:56 |
| jelly | honestly I half expected some distros to throw their hands in the air and go "everyone move to 4.14, upstream is crazy and we can't keep up" | 17:57 |
| mason | jelly: They've changed the upstream LTS to five years. | 18:00 |
| mason | Ooh. Six years. I was wrong. 4.14 would be supported upstream for just as long as 18.04. | 18:01 |
| mason | https://arstechnica.com/gadgets/2017/09/android-users-rejoice-linux-kernel-lts-releases-are-now-good-for-6-years/ | 18:02 |
| FingerlessGloves | jelly, still no luck, how odd :S | 18:02 |
| mason | jelly: And... At least according to kernel.org, 4.4 is still LTS. | 18:05 |
| jelly | mason: I'll believe that when I see latest KPTI in it | 18:12 |
| mason | jelly: http://news.softpedia.com/news/linux-kernels-4-14-11-4-9-74-4-4-109-3-16-52-and-3-2-97-patch-meltdown-flaw-519215.shtml ? | 18:13 |
| mason | I guess that's only half. | 18:14 |
| jelly | yeah, and then a kernel dev goes on record on reddit saying "patches for < 4.14 are based on older KAISER releases, with known bugs in them, we're not going to care" | 18:15 |
| mason | That goes along with the whole thing being an abominable mess I guess. :/ | 18:15 |
| jelly | nod | 18:15 |
| jelly | ok, not reddit, but a similar site https://news.ycombinator.com/item?id=16087736 | 18:20 |
| mason | Interesting. | 18:21 |
| jelly | six years would indeed be very very nice, I guess someone is trying to make android devices supported for a little bit longer, before someone like EU enforces it in law? | 18:24 |
| mason | That would be a huge boon. | 18:24 |
| jelly | and makes a decision not to skip it... actually rather weird | 18:24 |
| jelly | s/not // | 18:24 |
| sudormrf | nope didn't work | 18:43 |
| sudormrf | boooo | 18:43 |
| blackflow | huh, that spinics.net ml post, linked from the HN link above, about slowdowns on RedHat is bad news. I do suppose all of the pre 4.14 kernels are going to have hard time due to no PCID support, unless their distros backport that too. | 19:06 |
| blackflow | mess, indeed. | 19:06 |
| blackflow | and knowing the upstream stance on running latest kernels, indeed tracking HWE kernels in Ubuntu would be the best thing to do, so it doesn't matter if 18.04 does 4.14 or 4.15. as soon as 18.10's kernel is up in HWE, upgrade time. | 19:07 |
| mason | HWE can be hit or miss. | 19:11 |
| sudormrf | can anyone help me with using openSSL as a root CA? chrome is being a jerk about recognizing the cert I am generating and I don't know what I am missing from the configuration file. I am using SANs but Chrome says it doesn't have any | 19:55 |
| sudormrf | safari recognizes it just fine | 19:55 |
| === fyxim_ is now known as fyxim | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!