| lordievader | Good morning | 07:18 |
|---|---|---|
| rbasak | leftyfb: have you looked into Ubuntu IoT stuff? Read only images, atomic updates, etc. | 09:30 |
| ahasenack | cpaelzer: rbasak: hi, when any of you have a moment, I have this MP to unblock ldb in disco: https://code.launchpad.net/~ahasenack/ubuntu/+source/ldb/+git/ldb/+merge/359774 | 11:17 |
| rbasak | Looking | 11:20 |
| rbasak | done | 11:21 |
| cpaelzer | that was fast rbasak, I didn't even see it until now :-) | 11:37 |
| rbasak | Anything to distract me from this qemu+libvirt SRU review :-P | 11:41 |
| * cpaelzer sniff | 11:43 | |
| ahasenack | rbasak: hah, I did forget update-maintainers | 12:10 |
| ahasenack | ran it and pushed | 12:10 |
| rbasak | ahasenack: go ahead and upload, no need for me to look again | 12:10 |
| ahasenack | thx | 12:10 |
| cpaelzer | thanks rbasak | 12:20 |
| rbasak | yw | 12:21 |
| rbasak | Thank you for your diligence in preparing the update. Makes review easier. | 12:21 |
| rbasak | Lining up the patch names across the releases was a great help. | 12:22 |
| cpaelzer | yeah | 12:22 |
| cpaelzer | unfortunately the backports were different for the two target versions | 12:22 |
| rbasak | Yeah libvirt patch 5 threw me a little | 12:22 |
| cpaelzer | but as you said - I have hoped that keeping patch metadata and names intact would help | 12:22 |
| kstenerud | ahasenack: What does it mean when a bileto ticket is abandoned? | 12:22 |
| cpaelzer | rbasak: was that the fused one? | 12:22 |
| cpaelzer | rbasak: TBH IBM was the one fusing it into one, I personally would have preferred three stripped down patches. But then I was glad for their help - so no complaining | 12:23 |
| rbasak | I think so | 12:23 |
| rbasak | lp1787405-0005-qemu-Extract-MDEV-VFIO-PCI-validation-code-into-a-se.patch vs. lp1787405-0005-qemu-domain-device-definition-hostdev-validation.patch | 12:23 |
| cpaelzer | I see | 12:24 |
| rbasak | What I've been doing recently for similar SRUs is to first identify how the uploads are different between devel and the SRU target releases, and confirm I'm happy with those differences. Once done I reduce what I have left to review to one release only. | 12:26 |
| rbasak | (plus changelog and other metadata, but at least there's less meat that way) | 12:26 |
| ahasenack | kstenerud: I dropped it, since I was satisfied with the results and uploaded the package already | 12:29 |
| ahasenack | kstenerud: it will disappear in due time | 12:29 |
| muhaha | Anyone using Proxmox and using PXE to boot/install unattended install ? | 13:56 |
| talx | hello folks | 14:10 |
| ahasenack | rbasak: cpaelzer: hi again, ldb is basically done, but now I need a samba upload, which is a rebuild because of ldb bump, and a merge from debian: https://code.launchpad.net/~ahasenack/ubuntu/+source/samba/+git/samba/+merge/359776 | 14:25 |
| ahasenack | kstenerud: check "trying: ldb" in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt | 14:25 |
| ahasenack | kstenerud: this one is an indication that samba needs a rebuild, because of samba-dsdb-modules | 14:26 |
| kstenerud | ahasenack: So that means taht samba-dsdb-modules depends on ldb? | 14:26 |
| ahasenack | yes, a very strict dep | 14:27 |
| ahasenack | from d/rules (samba's): | 14:28 |
| ahasenack | # samba ships ldb modules, which are specific to the ldb version, so we need a | 14:28 |
| ahasenack | # strict dependency on the upstream ldb version | 14:28 |
| ahasenack | # this also mean samba needs a rebuild when the upstream ldb version changes | 14:28 |
| ahasenack | LDB_DEPENDS = "libldb1 (<< $(LDB_EPOCH):$(LDB_NEXT_VERSION)~), libldb1 (>> $(LDB_EPOCH):$(LDB_VERSION)~)" | 14:28 |
| * ahasenack -> lunch | 14:29 | |
| ahasenack | rbasak: when you say "Since we can't easily unpin with a cached copy of pylint", you are talking about https://people.canonical.com/~rbasak/git-ubuntu/pylint-1.7.2.tar.gz or something else that snapcraft caches? | 15:55 |
| rbasak | ahasenack: yeah, the p.c.c one. | 16:18 |
| ahasenack | rbasak: ok | 16:34 |
| Pcost8300 | hello Everyone and good afternoon, I would like to know if changing an Ubuntu Server 14.04 Time to just one hour up could cause any trouble with databases or the glassfish server that is running in there. | 16:47 |
| lordcirth | Why do you need to change the time? Is it currently wrong? | 16:48 |
| rbasak | Pcost8300: if you change the server's idea of UTC, then that will break things. Changing the server's timezone is generally fine though. | 16:49 |
| Pcost8300 | rbasak: Thank you for the information, when i type date command it says time with CST 2018 at the end | 16:54 |
| Pcost8300 | rbasak: sorry for asking but what does it mean | 16:55 |
| Greyztar | Central Standard Time no? | 16:57 |
| rbasak | He's gone | 16:57 |
| Greyztar | :/ | 16:57 |
| ahasenack | rbasak: around still? https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1805178 is asking to have apparmor allow access to /etc/letsencrypt for the certificates, is the "canonical" place for the certs? What is its structure? | 18:39 |
| ubottu | Launchpad bug 1805178 in openldap (Ubuntu) "Apparmor should include letsencrypt directory for Slapd" [Undecided,New] | 18:39 |
| rbasak | ahasenack: IIRC, /etc/letsencrypt/live/$domain/ and then pem and keys in there | 18:44 |
| rbasak | ahasenack: private keys are very sensitive. I'm not sure it makes sense to default to giving all services access to them. | 18:45 |
| ahasenack | rbasak: can you imagine us shipping some sort of default allow-to-read apparmor role? | 18:45 |
| ahasenack | yeah | 18:45 |
| ahasenack | I'm inclined to suggest that users override that locally when needed | 18:45 |
| rbasak | For example, if I were running an HTTPS server, it may be the completely wrong thing for a compromise of slapd to compromise the key | 18:45 |
| rbasak | Maybe jjohansen and/or jdstrand have an opinion on that: ^ | 18:45 |
| ahasenack | I was hoping that /etc/letsencrypt structure would include the service name, or user name | 18:45 |
| rbasak | AIUI letsencrypt makes no distinction on service name. | 18:46 |
| rbasak | Everything is HTTPS, but you apparently can re-use certs for other services | 18:46 |
| ahasenack | I mean, the directory structure could be something like /etc/letsencrypt/slapd/*.pem | 18:46 |
| rbasak | (and you don't need HTTP/HTTPS to get a cert, since you can use DNS to prove domain ownership) | 18:46 |
| sdeziel | ahasenack: I the same cert for various services (postfix + dovecot typically) | 18:46 |
| ahasenack | yeah, the re-use makes this more complicated, if it's common | 18:46 |
| sdeziel | s/I the/I use the/ | 18:47 |
| ahasenack | apparmor ships with two abstractions related to certificates | 18:47 |
| ahasenack | /etc/apparmor.d/abstractions/ssl_certs and /etc/apparmor.d/abstractions/ssl_keys | 18:47 |
| ahasenack | they are not pulled in by default | 18:48 |
| ahasenack | maybe we could have an letsencrypt abstraction, and let the user decide what he/she wants (or augment the existing ones for letsencrypt) | 18:48 |
| * ahasenack just noticed that he is not in #ubuntu-hardened | 18:48 | |
| sdeziel | with the proliferation of Let's Encrypt clients, it will be hard to catch up with abstractions | 18:49 |
| * sdeziel uses local/ includes | 18:50 | |
| teward | sdeziel: ahasenack: it sounds like this should be posed to the Security team for additional consideration/review as well? | 18:50 |
| teward | because such additional abstractions to /etc/letsencrypt or {Insert Paths Here} can be security concerns in and of themselves | 18:51 |
| teward | (read: privkey security, etc.) | 18:51 |
| ahasenack | sure | 18:51 |
| jjohansen | rbasak: hrmmm I need to spend some time looking at this to have an informed opinion. I don't like having a default that might be wrong on servers | 18:56 |
| jjohansen | I agree with teward that this should go to the security team for additional consideration | 18:57 |
| teward | rbasak: ahasenack: in *theory* I agree with the idea for the apparmor access via an abstraction | 18:58 |
| teward | but from the **security** side of theory I have some very harsh critiques for the practice | 18:58 |
| teward | in sysadmin and ease of use theory* | 18:58 |
| ahasenack | there is one such abstraction already, fwiw | 18:59 |
| teward | because as rbasak says, private key sensitivity | 18:59 |
| teward | ahasenack: the second part of the argument is catching up with all the clients | 18:59 |
| ahasenack | I fully expect a wide range of paranoid levels around this issue | 18:59 |
| jjohansen | I marked the bug public security for now | 18:59 |
| ahasenack | for now I suggested in the bug that he use the apparmor.d/local mechanism to add his local changes | 18:59 |
| ahasenack | and asked what's the structure of his /etc/letsencrypt directory | 19:00 |
| teward | +1 for local abstractions per your suggestion ahasenack | 19:00 |
| ahasenack | teward: about the "all the clients" argument, we should first think about what the ubuntu client (certbot in this case) does | 19:00 |
| teward | +1 | 19:00 |
| ahasenack | I subscribed to the bug, will know when there is a reply | 19:00 |
| ahasenack | thanks for the quick discussion :) | 19:00 |
| teward | ahasenack: AIUI, /etc/letsencrypt/live/*/[crt,key,etc. here] is where it'd need to be reading | 19:00 |
| teward | * for the individual domain(s) as masters on the cert | 19:01 |
| teward | and then the individual certs and keys under that | 19:01 |
| ahasenack | ok | 19:01 |
| teward | as well as the CA chain where needed | 19:01 |
| sdeziel | the only sensitive part in there is the key so is it root owned and with a special extension (like .key)? | 19:03 |
| teward | I think so *double checks his LE test system* | 19:03 |
| sdeziel | thanks, I only use dehydrated myself :) | 19:03 |
| teward | sdeziel: actually, access to the dir might be tricky | 19:04 |
| rbasak | jjohansen: understood. Thanks! | 19:04 |
| teward | sdeziel: live/* root:root 700 | 19:04 |
| sdeziel | teward: most daemons start as root so what's your concern? | 19:04 |
| teward | sdeziel: true, but in cases where a daemon woudln't it wouldn't have access | 19:05 |
| teward | i'm not familiar as much with openldap, it starts as root I assume? | 19:05 |
| sdeziel | teward: probably since it bind port 389 and/or 686 | 19:05 |
| teward | i just realized I don't have latest certbot on this system :| | 19:06 |
| teward | sdeziel: at least with 0.22.2, /etc/letsencrypt/live/*/privkey.pem | 19:06 |
| teward | but i'mma have to spin a bionic for newer testing | 19:06 |
| teward | ... once I get home (can't access my infra at home for better testing from here at the moment) | 19:07 |
| sdeziel | teward: thanks | 19:07 |
| teward | sdeziel: but everything in that folder is a *.pem so it's not a special extension to specify the key | 19:08 |
| teward | IIRC this is still the way it behaves today in latest but eh | 19:08 |
| teward | ... oh THERE'S my VPN keys... I was looking for these earlier to VPN back home >.> | 19:09 |
| sdeziel | so far, the safest way I found (please let me know of any flaw) is to have an install/deploy hook to put the cert/key in /etc/$daemon/certs/ and make them root:root 0600. Combined with this Apparmor rule: "/etc/$daemon/certs/* r," | 19:10 |
| teward | sdeziel: 30/60d cert regen means you need to redeploy the cert each time, unless I misunderstand what you mean by 'deploy hook' | 19:11 |
| sarnold | root:root may mean you've got to run your daemon at higher-than-needed privs | 19:11 |
| teward | duh I forgot sarnold was in here LOL | 19:12 |
| teward | *facedesks, then goes to find more caffeine* | 19:12 |
| sarnold | don't take that to mean I'm *paying attention* | 19:12 |
| sdeziel | sarnold: for the services I manages, most of them keep a master process (nginx, postfix, dovecot) so a simple reload is enough to pick up the new cert/key. prosody is an outlier here though | 19:13 |
| teward | sarnold: no, I just meant I can ping you and annoy the heck out of you on these things in here *evil grin* | 19:13 |
| sarnold | sdeziel: nice | 19:13 |
| teward | :P | 19:13 |
| sarnold | ah :) | 19:13 |
| sdeziel | to improve on the Apparmor rules, I guess that leveraging the hardcoded names would work "/etc/$daemon/*chain.pem r," and "owner /etc/$daemon/privkey.pem r," | 19:14 |
| sdeziel | and I forgot the $domain so they should all be prefixed /etc/$daemon/*/ to support whatever CN you happen to use | 19:15 |
| sdeziel | anyway, I like this scheme better than all the keys in /etc/ssl/private | 19:17 |
| sdeziel | teward: yes, I re-deploy certs and keys all the time (I don't reuse keys) | 19:20 |
| Greyztar | setting after and wants in systemd service file ,will that make the parent service not start until the dependencie is successfully started? | 20:03 |
| lordcirth | Greyztar, that's the idea, yes | 20:20 |
| Greyztar | lordcirth: ive been doing some reading,just wanted it confirmed as google can be sometimes well...thanks for answering me (,") | 20:21 |
| lordcirth | np | 20:23 |
| docmur | I have a fresh apache2 setup with two domains configured 000-default.conf and test.conf, whe nI try to navigate to test.ca, I'm getting the default location /var/www/html returned and not /var/www/test, these are the config files: https://pastebin.com/L8LYfH6x | 22:22 |
| docmur | shouldn't that work? | 22:22 |
| docmur | I just did a purge and install of apache2 so everything else should be generic | 22:22 |
| Greyztar | when sourcing a file with some variables or so in bash,that would only last current session no?So when a reboot takes places what have been sourced is gone? | 22:29 |
| mybalzitch | will changes made by ovs-vsctl to add/remove ports persist through a reboot? | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!