[04:21] <hallyn> cpaelzer: the list is always too long :(  sad thing is the cycles they go in.  when i first joined, there were a lot of issues around net connectivity and live migration :)
[05:37] <cpaelzer> hallyn: yeah thanks for your sentiment - it raises me up to hear that I don't feel like that alone and that it was the same "before me"
[06:01] <cpaelzer> rbasak: hey if you are around - could you import virt-manager into usdi?
[06:02] <cpaelzer> I want to look ho complex the Delta looks like when I split it up
[06:02] <cpaelzer> and when I start I can as well prepare for the case that I might merge it - so usdi would be helpful
[10:20] <ws2k3> is there something wrong with the ubuntu installer? i just installed ubuntu 16.04 and it refuses to boot. i installed it twice to make sure i didnt do anything wrong
[10:36] <ikonia> "refuses to boot" isn't really a problem description
[10:58] <cpaelzer> rbasak: I don't really need virt-manager in usdi itself, I currently try to import it myself locally
[10:58] <cpaelzer> rbasak: if it ends up with a working git tree I'm good
[11:10] <rbasak> cpaelzer: I've been importing it for a while. It's on unapplied xenial currently
[11:11] <rbasak> cpaelzer: in theory the hashes should match your import. So it'll be interesting to see if that happens.
[11:13] <rbasak> It's just started on applied now
[11:14] <cpaelzer> mine is in applied for about 15-20 minutes now
[11:15] <cpaelzer> yeah, interesting if all hashes match :-)
[12:11] <cpaelzer> rbasak: would you have 15 minutes for some conffile fun somewhen today?
[12:11] <cpaelzer> rbasak: I'll need to do a summary writeup for a clearer discussion - so not now (at least 15 minutes or so)
[12:12] <cpaelzer> rbasak: but I'd appreciate to find one to discuss some details before working on a proposed fix
[12:22] <rbasak> cpaelzer: sure
[12:23] <rbasak> cpaelzer: import complete
[12:34] <ahasenack> hi, does anybody know what this is about? https://launchpadlibrarian.net/234346016/DpkgTerminalLog.txt "innserv" is in a loop apparently
[12:34] <ahasenack> maybe https://bugs.launchpad.net/ubuntu/+source/insserv/+bug/541023
[12:35] <ahasenack> from the lucid (!) days
[12:35] <cpaelzer> ahasenack: yeah I've seen those in the past
[12:35] <cpaelzer> ahasenack: in 95/100 cases people have ppas or even "more out of archive" packages/tarballs installed
[12:35] <cpaelzer> ahasenack: those mess up the system by placing things in init scropts which lead to loops at the dependency resolution
[12:36] <cpaelzer> ahasenack: mostly it is about spotting the uncommon name in the logs and asking where this file is from (dpkg -S"
[12:36] <ahasenack> insserv shouldn't be used anymore, right?
[12:36] <tomreyn> depends on your ubuntu release, which you have not yet disclosed
[12:37] <ahasenack> 15.10 in that case
[12:37] <tomreyn> well that's unsupported for a good while now :(
[12:37] <cpaelzer> ahasenack: if you have a low maintenance old package even insserv is fine - it will install its stuff and the systemd-generator will pick it up
[12:38] <ahasenack> it could be "smfpd", I don't recognize that name:
[12:38] <cpaelzer> so you see it here and there in packages that don't care about systemd yet but instead rely on the compat handling
[12:38] <ahasenack> insserv: Starting smfpd depends on ondemand and therefore on system facility `$all' which can not be true!
[12:38] <ahasenack> tomreyn: sorry, let me clarify. It's not my system, it's a bug filed by someone
[12:38] <ahasenack> against "samba"
[12:38] <ahasenack> but I've seen others like this filed against random packages when the real problem is insserv
[12:39] <tomreyn> oh okay, also for supported releases then?
[12:39] <cpaelzer> ahasenack: as I said before the "real problem" IMHO mostly is out-of-archive software
[12:39] <cpaelzer> I've seen messages like that up to and including zesty every now and then
[12:39] <ahasenack> tomreyn: no, wily, I'll close it but add a note that it's not in samba
[12:39] <ahasenack> tomreyn: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1534944
[12:39] <ahasenack> it got in my radar because of the last comment, "confirmed"
[12:40] <ahasenack> which made me get an email :)
[12:40] <cpaelzer> ahasenack: and if you want to do him a favor ask him to do a dpkg -S on /etc/init.d/smfpd
[12:40] <tomreyn> oh you're bug triaging, sorry i thought you were seeking support.
[12:40] <ahasenack> tomreyn: yep :)
[12:40] <ahasenack> cpaelzer: good idea
[12:41] <ahasenack> I think there are hundreds of apport-reported bugs against eol releases now
[12:42] <cpaelzer> yep ahasenack
[12:43] <cpaelzer> ahasenack: we have the discussion if we should mass-close them or something like it every now and then
[12:43] <cpaelzer> ahasenack: bring it up next week, it might be time to have that talk again
[12:43] <ahasenack> cpaelzer: I think dpb1 will favor that
[12:44] <ahasenack> I will add it to the agenda
[12:44] <ahasenack> although I think he has something like that already in it
[12:45] <cpaelzer> ahasenack: my opinion last time was to only process those that are on ubuntu-server subscription and for those do the extra work of really checking on newer versions
[12:46] <ahasenack> cpaelzer: it's tough when the bug happened during apt upgrade and the logs are not conclusive, it's almost impossible to get into that same scenario again
[12:46] <ahasenack> updates have been issued and superseeded older packages which are no longer available
[12:47] <ahasenack> sometimes the user refuses to add extra logs, for privacy concerns, and it's awkward to start a dialogue 2-3 years later "hey, could you please attach /etc/foo/bar.conf?"
[13:00] <cpaelzer> ahasenack: I'm not objecting :-)
[13:00] <cpaelzer> ahasenack: yet it will make the "ubuntu gives up on 12345678 bugs" post go around the world
[13:01] <ahasenack> will make it clear though
[13:01] <ahasenack> but deserves a discussion
[13:01] <cpaelzer> which is what I suggested and you agreed, so we are on the path
[13:01] <cpaelzer> did you add to the agenda?
[13:02] <ahasenack> just did
[13:02] <ahasenack> cpaelzer: sprint agenda
[13:02] <ahasenack> dpb1 had a topic already, I expanded it a bit
[13:20] <zul> jamespage:  pinghttp://pastebin.ubuntu.com/24714955/ (fyi)
[13:26] <PresidentTrump> I want to run npm install as http user but http user is nologin. I prefer not to run as root and then chown to http. npm install is being run by a systemd script.
[13:28] <dpb1> PresidentTrump: you can: sudo chsh -s /bin/bash http
[13:29] <ogra_> or just sudo apt install npm
[13:30] <dpb1> ogra_: he wants to npm install, not install npm.  funny turn of words. :)
[13:30] <ogra_> eeep ... indeed ... blind me, sorry for the noise
[13:30] <ogra_> :)
[13:31] <PresidentTrump> thanks
[13:36] <ahasenack>     raise ProvisioningError("Your filesystem or build does not support posix ACLs, which s3fs requires.  "
[13:36] <ahasenack> hm, zfs
[13:36] <ahasenack> nsn7/lxc on /var/lib/lxc type zfs (rw,noatime,xattr,noacl)
[13:36] <ahasenack> :(
[13:39]  * ahasenack inspects zfs set acltype
[13:41] <ahasenack> yay
[13:41] <ahasenack> nsn7/lxd/containers/zesty-samba-ad on /var/lib/lxd/storage-pools/default/containers/zesty-samba-ad type zfs (rw,noatime,xattr,posixacl)
[13:42] <ikonia> thats interesting your running a samba service to replicate AD in a container ?
[13:42] <ahasenack> the container is just the development aspect of it, I'm doing some testing
[13:43] <ikonia> is it doing a full AD substitute ?
[13:43] <ahasenack> it should, but it's the first time I set samba up like that
[13:43] <ahasenack> they have a nifty tool nowadays
[13:43] <ahasenack> just run "samba-tool domain provision"
[13:43] <ikonia> interesting, standalone or will it integrate into an existing AD setup ?
[13:44] <ahasenack> what I'm trying is standalone. It sets up kerberos, dns, ldap
[13:44] <ahasenack> joining an ad forest is simpler
[13:44] <ikonia> very interesting indeed
[13:44] <ikonia> well....maybe not
[13:44] <ikonia> as I'm curious to how the AD txt/srv records would be managed with containers
[13:44] <ikonia> and an overlay network
[13:45] <ahasenack> you just don't use the dnsmasq services
[13:45] <ahasenack> use a static ip, setup bind, rndc keys
[13:45] <ahasenack> use the container as if it were a vm
[13:46] <ahasenack> I attached this container to a libvirt-managed network where there is no libvirt-provided dhcp (dnsmasq)
[13:46] <ikonia> bind is a dns server, it won't manage the txt and srv records an AD service would require/generate
[13:46] <ahasenack> samba4 can either use bind, or its own internal implementation
[13:46] <ahasenack> the default is its own internal implementation
[13:46] <ahasenack> same for ldap
[13:46] <ikonia> hence why I'm curious how hooking it into an AD service that is expecting to manage it's own DNS would work
[13:46] <ahasenack> in the ldap case, it can't use any other ldap implementation actually
[13:47] <ikonia> yes, Samba can, but AD can't
[13:47] <ikonia> hence why joining the forest is of inerest
[13:47] <ikonia> interest
[13:47] <ahasenack> I'll get to that at some point :)
[13:47] <ahasenack> right now I'm checking a bug report
[13:49] <ikonia> be interested how you get on with that
[13:49] <ikonia> especially with a container and an overlay network
[14:03] <ahasenack> hm, finding some rough spots in the samba4 packaging
[14:03] <ahasenack> when setting up an ad dc
[14:04] <ahasenack> but ok, got it to work
[14:06] <ahasenack> http://pastebin.ubuntu.com/24715338/
[14:12]  * ahasenack finds the rough spots in the TODO.Debian file
[14:36] <Da9el> En fra dk der lige kan hjælpe med en SSH der driller
[14:38] <mason> Da9el: er der en liste her, der kan hjælpe: https://lists.ubuntu.com/mailman/listinfo/ubuntu-dk
[14:40] <Da9el> Okay må jeg prøve tak
[14:40] <mason> Da9el: Held og lykke.
[15:49] <teward> is there a server team meeting or was it postponed?
[15:50] <teward> or cancelled
[15:51] <dpb1> teward: there is, in 10m
[15:52] <teward> cool, wasn't sure :)
[15:52] <teward> i'll be there.  ish.
[15:52] <teward> *still trying to figure out IPv6-from-public-to-LXD-container stuff*
[15:52] <dpb1> teward: :)
[15:53] <teward> did I happen to mention that IPv6 is painful
[15:53] <teward> or is that just 'implied' now
[16:21] <nacc> jamespage: any luck with your artful runs for openstack with new django?
[17:01] <jonfatino> So it seems casper doesn't support http fetch of filesystem.squashfs. I found a patch on https://forum.kde.org/viewtopic.php?f=309&t=136596 but it doesn't seem to be working with the latest initrd/scripts/casper
[17:02] <jonfatino> Perhaps someone can take a look at the altered initrd/scripts/casper file and fix it up?  https://pastebin.com/V6W39XJu
[17:47] <PresidentTrump> what is the proper way to deploy passwords as env on production servers? add them to /etc/environment ?
[17:47] <nacc> PresidentTrump: why would you ever want to do that?
[17:52] <PresidentTrump> nacc, https://caddyserver.com/docs/automatic-https see section under enabling dns challenge
[17:55] <nacc> PresidentTrump: i see -- it seems dangerous to store credentials in the environment, but that's just me
[17:56] <PresidentTrump> nacc, would storing them in the systemd file be safer?
[17:57] <PresidentTrump> systemd has a method of setting variables
[17:57] <nacc> PresidentTrump: i'm not sure -- it just seems 'dangerous' to put credentials like that anywhere that if you were to get hacked, then all of a sudden the hacker has access to everything else
[18:00] <PresidentTrump> nacc, if they hack into the server don't they already have access to everything
[18:00] <PresidentTrump> database passwords are there
[18:00] <nacc> PresidentTrump: i assume your database passwords are encrypted
[18:01] <nacc> PresidentTrump: i'm saying if your server is hacked and your credentials are stored in plaintext in the environment or in a systemd file, that seems odd
[18:03] <PresidentTrump> nacc, if its encrypted then how can the application access the database?
[18:03] <nacc> PresidentTrump: different problem, i'm just looking at the idea of storing credentials in the environment
[18:03] <PresidentTrump> and its encrypted but the key is also stored on the server then it serves no purpose
[18:04] <PresidentTrump> can I get a practical answer?
[18:05] <PresidentTrump> there is no point on focusing on securing credentials when there is lower hanging fruit
[18:06] <PresidentTrump> 99% of small websites out there are far more insecure
[18:06] <ahasenack> PresidentTrump: /etc/environment is meant to be read by all users of the system at login time. Isn't it just one user who needs access to this password?
[18:06] <PresidentTrump> yes
[18:06] <ahasenack> does it have to be a shell variable? Can it be a file in the user's /home directory for example?
[18:07] <PresidentTrump> ahasenack, can you look at the caddy documentation I linked to?
[18:07] <PresidentTrump> is there a way for it not to be a shell env?
[18:07] <PresidentTrump> I think the most sensible way of making it a single application env is to add it to the systemd file
[18:08] <ahasenack> is that a daemon?
[18:09] <ahasenack> I think in systemd you can refer to a file that has your variables
[18:09] <ahasenack> that sounds ok. You would make that file 0600 then or something like that
[18:09] <ahasenack> or have whatever script starts the daemon source the file with the variables
[18:10] <ahasenack> but not /etc/environment, that is system-wide and meant to be 0644
[18:10] <PresidentTrump> ahasenack, so I have a bash script that needs the vars too
[18:10] <ahasenack> it can source that file that the systemd config is sourcing
[18:10] <ahasenack> I don't recall the systemd configuration key now, sorry
[18:10] <PresidentTrump> ahhhh
[18:10] <PresidentTrump> right I should use source...
[18:10] <PresidentTrump> thanks
[18:10] <ahasenack> I checked upon that once when researching how to pass proxy variables to a service
[18:14] <ahasenack> nacc: hi, the bug I need sponsoring on, following up our irc meeting: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1677329
[18:14] <ahasenack> it has a branch attached
[18:14] <ahasenack> meant for artful
[18:17] <nacc> ahasenack: reviewing
[18:17] <ahasenack> nacc: thx
[18:48] <ahasenack> nacc: thanks for the review
[18:49] <nacc> ahasenack: np, does it make sense?
[18:49] <ahasenack> yes
[18:49] <ahasenack> :)
[18:50] <nacc> ahasenack: feel free to fix up and push back over the top, i'll pull your changes down and re-review whenever you need
[18:50] <ahasenack> ok