[06:58] <lordievader> Good morning
[08:14] <Jeffrey4l> where is the packaging source code for ubuntu cloud archive repo?
[12:07] <ktosiek> Is there any tool for managing upgrades for multiple servers other than Landscape and apt-dater?
[12:07] <ktosiek> I'd love to have a workflow where I can see upgrades per package, and then apply them to specific groups of servers
[12:29] <yeats> ktosiek: puppet? ansible? (totally different approaches, each requiring forethought and up-front configuration setup)
[12:33] <ktosiek> I'm using Ansible for some hosts, but I could use a nice package-oriented dashboard :-)
[12:41] <patdk-lap> ya, ansible and puppet/chef are backwards on how they think
[13:17] <rbasak> patdk-lap: how do you think they should think?
[13:19] <patdk-lap> I don't understand how that has to do with anything
[13:20] <patdk-lap> that is like asking me, how linux and windows should work
[13:21] <patdk-lap> they are two totally different things designed for different purposes
[13:23] <rbasak> I thought you were making a general statement.
[13:23] <patdk-lap> I did
[13:24] <patdk-lap> puppet/chef conforms a system to a model you define
[13:24] <patdk-lap> ansible conforms the app to the system
[13:24] <rbasak> Oh
[13:24] <patdk-lap> they work backwards
[13:24] <rbasak> "ya, (ansible) and (puppet/chef are backwards on how they think
[13:24] <rbasak> Uh
[13:25] <rbasak> "ya, ((ansible) and (puppet/chef)) are (backwards on how they think)
[13:25] <rbasak> Is what you meant.
[13:25] <rbasak> "ya, (ansible and puppet/chef) are (backwards on how they think)
[13:25] <rbasak> "
[13:25] <rbasak> Is what I thought you meant.
[13:25] <rbasak> I follow now :)
[13:56] <xnox> rbasak, hey, php7.1->7.2 transition is done, however php7.1 cannot yet be removed because there are packages that depend on the removed php-mcrypt (no longer provided by php7.2)
[13:56] <xnox> rbasak, do you know if anybody knows how php packaging works, to potentially package this https://pecl.php.net/package/mcrypt standalone php mcrypt library?
[13:56] <rbasak> xnox: nacc was talking about that on Friday
[13:56] <xnox> rbasak, ah, cool. Is he going to do it?
[13:57] <rbasak> He had some options in mind I think.
[13:57] <rbasak> I'd rather wait for him than relay his opinions badly :)
[13:57] <xnox> ok
[13:57] <xnox> i'll try to catch up with him.
[14:46] <cpaelzer> smoser: hi on your open-vm-tools question
[14:47] <cpaelzer> smoser: is that because you still assume that privateTmp is not what triggers the bug?
[14:47] <cpaelzer> and you'd be interested to see what actually fails (via the strace) ?
[14:59] <smoser> cpaelzer: yeah, i was going to see strace.
[14:59] <smoser> i'd rather actually know what is the problem.
[14:59] <smoser> if it is privatetmp, then we need to file a bug on systemd
[14:59] <smoser> but i suspect it is not
[14:59] <smoser> so i'd like actual reason for failure.
[15:05] <cpaelzer> smoser: ok, so my assumption what you were after was correct at least
[15:05] <cpaelzer> trying to get some data on it
[15:05] <cpaelzer> ...
[16:45] <cpaelzer> smoser: it is a systemd issue
[16:45] <cpaelzer> smoser: I updated the bug with some more details that would flood the chan
[16:49] <smoser> cpaelzer: local-fs.target is no where near the same thing as a dependency on private tmp
[16:50] <smoser> local-fs.target means a dependency on /opt/some/path if /opt/some/path is in /etc/fstab.
[16:51] <xnox> smoser, note that PrivateTmp= generates implicit dependencies already - Similar, units with PrivateTmp= enabled automatically get mount unit dependencies for all mounts required to access /tmp and /var/tmp
[16:51] <xnox> https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Implicit%20Dependencies
[16:52] <xnox> one more obscure "helpful" systemd feature.
[16:52] <nacc> heh
[16:52] <smoser> xnox: yes.
[16:52] <smoser> as figured out https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1750780
[16:52] <xnox> nacc, hi!
[16:52] <nacc> xnox: hiya
[16:52] <smoser> but it doesnt do that in xenial
[16:52] <smoser> but that said, a mount of /tmp and /var/tmp != local-fs.target
[16:52] <nacc> rbasak: did you want to sync on git-ubuntu today? (mini-sprint to get phasing going this week?)
[16:52] <smoser> where local-fs.target is all mounts in /etc/fstab
[16:52] <xnox> nacc, what's up with packaging php-mcrypt from https://pecl.php.net/package/mcrypt ?
[16:53] <smoser> including /opt/some/random/path
[16:53] <nacc> xnox: i pinged ondrej on it and he said he would not do it in debian
[16:53] <xnox> nacc, i think that's the easiest way forward, to remove php7.1
[16:53] <nacc> xnox: i have a bug filed
[16:53] <nacc> xnox: we just need to remove two more source packages
[16:53] <xnox> nacc, sure, but i think we should, until it's done in debian.
[16:53] <nacc> one of which i've talked to upstream about and they don't want it pacakged in ubuntu :)
[16:53] <xnox> nacc, hm, ok. Do you have bug number?
[16:53] <nacc> xnox: yeah, sorry was looking it up https://bugs.launchpad.net/bugs/1749745
[16:54] <xnox> nacc, from http://people.canonical.com/~ubuntu-archive/nbs.html it's 6, no?
[16:54] <xnox> ah
[16:54] <nacc> xnox: iirc, tsome of those are reverse-recommends, but let me check
[16:54] <xnox> ah, could be.
[16:54] <nacc> xnox: yeah the last 3 are recomends
[16:54] <xnox> i think we can upload dropping reverse-recommends.
[16:55] <nacc> xnox: yeah, i can do that today
[16:55] <nacc> and then we'd remove cakephp{,-scripts} and gosa
[16:55] <nacc> i think gosa will come back in, as i've talked to upstream abou tit
[16:55] <nacc> but i'd rather we sync it from debian then try to diverge right now
[16:56] <xnox> yeah =/
[16:56] <nacc> xnox: i'll work with the AAs on the removals today
[16:56] <xnox> cool
[16:59] <smoser> xnox: could you take a *quick* look at  my scary systemd-resolve bug ?
[17:00] <smoser> i can't understand why anyone using network manager on bionic would not be affected.
[17:00] <rbasak> nacc: yep. Five minutes?
[17:01] <Sircle> Hi
[17:01] <Sircle>  How to make sure that .php script of one site cannot access data of any other site?
[17:02] <xnox> smoser, something is very odd
[17:02] <xnox> smoser, so  DNS Domain: ~mosers.us does not look right.
[17:02] <Sircle>  I am having hard times in blocking access to the directory ".git" and any files under its tree. This directory is in every of my 70 websites. What should I do ? I have referred http://httpd.apache.org/docs/current/mod/mod_authz_core.html#require    but cannot make up syntax
[17:02] <xnox> smoser, i think you may be able to fix it by sending the right domain to resolved via d-feet.
[17:03] <xnox> smoser, i believe it is set to "route-only" ~mosers.us => meaning, only use this network for mosers.us and nothing else.
[17:03] <xnox> i think, it should be "mosers.us" there instead.
[17:03] <nacc> rbasak: ack
[17:03] <xnox> smoser,           DNS Domain: ~mosers.us
[17:03] <xnox> is the odd bit, because for me, it is
[17:03] <xnox> smoser,           DNS Domain: surgut.co.uk
[17:03] <nacc> Sircle: ok, cross-posting *three* times does not help
[17:04] <xnox> Sircle, hm, you should not store .git in public directories.... if you deploy from git, you should export a tree from git, not clone a git repository....
[17:04] <sdeziel> Sircle: you can have the .git reside outside of the documentroot and then you can set permissions on it to prevent the www-data user from accessing it
[17:05] <xnox> Sircle, or are you trying to serve naked git dir / as in host git repositories over http? then it should not be /.git/ subdir, but a full top level one, like myrepo.git/
[17:06] <xnox> smoser, are you using, something like "use this connection only for things on behind this connection" in network manager?
[17:07] <smoser> xnox: have you rebooted ?
[17:07] <nacc> rbasak: i'm in the standup HO
[17:07] <rbasak> omw
[17:08] <xnox> smoser, not recently no, maybe i should.
[17:08] <smoser> i do not have 'use this connection fo resources ...'
[17:08] <xnox> smoser, i am close to end of day, and will reboot and debug this stuff. I do think we may need changes to make sure it sends domains as "search & route", not "route-only".
[17:08] <Sircle> xnox,  let me know the syntax?
[17:08] <xnox> smoser, as looking at resolved dns plugin inside network manager, it did look wrong to me before.
[17:09] <xnox> Sircle, sorry, i do not provide support at that level. And i'm not sysadmin myself.
[17:14] <cpaelzer> xnox: smoser: don't focus on local-fs.target != "dependency on private tmp" that is the easy to resolve path in bionic
[17:14] <cpaelzer> focus on the trivial unit that I added to the bug that fails in Xenial by NOT having those implicit dependencies
[17:18] <smoser> cpaelzer: i'm not able to reproduce your failure
[17:18] <Sircle> xnox,  nacc sdeziel I need www-data to access .git to take pulls
[17:18] <smoser> yeah. i dont understand it.
[17:19] <smoser> unless /tmp and /var/tmp are on a different filesystem then / then i am missing something
[17:20] <sdeziel> Sircle: if you need www-data to access the .git dir but not PHP, I think you can use PHP-FPM and run it with a non www-data user
[17:20] <Sircle> sdeziel,  there are many httpd rules like I mentioned above to deny access.
[17:21] <sdeziel> Sircle: deny rules affect clients access, not what apache/mod_php can do
[17:36] <Sircle> sdeziel,  I want to deny client acccess. yes.
[17:53] <nacc> powersj: ping
[17:54] <powersj> nacc: sup
[17:55] <nacc> powersj: wanted to sync on the git-ubuntu CI. i'm about to land the changes in master that will make us need to switch to the new CI jobs
[17:55] <nacc> powersj: we had chatted last week about making there be 3 stages or so? snap build, snap self-test, integration test ?
[17:55] <powersj> nacc: yeah I am finishing 16.04.4 testing now, then I can work on the workflow
[17:55] <nacc> powersj: ack, thanks
[17:56] <nacc> powersj: do you want me to hold off on landing in master? or can you run against master to show the potential output?
[17:56] <powersj> nacc: I'd actually prefer it be in master, so I can use it to test the workflow
[17:57] <nacc> powersj: ack, landing them now then
[18:55] <ahasenack> mdeslaur: that clamav 0.99.3 update somehow reverted the NEWS file to talk about 0.99.1, did you notice that?
[19:10]  * mdeslaur looks
[19:11] <mdeslaur> ahasenack: what news file are you referring to? the one I see mentions 0.97.5
[19:12] <ahasenack> mdeslaur: "NEWS" at the root
[19:12] <ahasenack> mentions 0.99.1
[19:12] <Sircle> sdeziel,   I have 70 directories under /var/www/html/   Do I need to put <Directory for each of 70  or just something like <DirectoryMatch /var/www/html/*/.git/*> ?
[19:12] <ahasenack> in the 0.99.3+addedllvm-0ubuntu1 package, and also in upstream's 0.99.3 tarball
[19:12] <mdeslaur> ahasenack: yes, that's normal...upstream's 0.99.3 tree actually got renamed to 0.100 when they decided 0.99.3 should be a minor update to 0.99.2
[19:13] <mdeslaur> ahasenack: so the 0.99.3 betas have nothing in common with the actual 0.99.3 release
[19:13] <ahasenack> hmm
[19:13] <ahasenack> so we got a downgrade?
[19:13] <ahasenack> there was no fix for the 0.99.3 betas (or 0.100)?
[19:13] <mdeslaur> yes, we downgraded to the stable release
[19:14] <mdeslaur> there's no release for 0.100, it's a work in progress
[19:14] <ahasenack> since we were using a beta already, couldn't we have upgraded to 0.100?
[19:14] <ahasenack> wouldn't the code diff be smaller?
[19:15] <mdeslaur> you want to ship an unfinished work in progress with no release date and possibly no proper signatures in our LTS release?
[19:15] <ahasenack> wasn't it like that already with 0.99.2~beta?
[19:15] <ahasenack> or rather, 0.99.3~beta
[19:15] <mdeslaur> yes, and we should have never synced that
[19:16] <ahasenack> ah
[19:54] <Sircle> I had files in /var/www/html/site1.com   /var/www/html/site2.com and so on. One of my sites got compromised and script in it copied many files inside other website directories. How can I restrict this so php cannot access files outside the parent directory or vhost path?
[19:54] <Sircle> nacc,  xnox sdeziel
[19:54] <nacc> Sircle: don't use php? :)
[19:54] <nacc> Sircle: please don't ping users with random questions
[19:54] <Sircle> k
[19:55] <sarnold> do not let the user that runs the php code have write access to anything except log files, database sockets, and an uploads directory if you absolutely must have one
[19:55] <sarnold> you can use both unix access control mechanisms and AppArmor for this task
[19:56] <Sircle> No way to isolate each site?
[19:58] <Sircle> sarnold, For access rights, it varies so much. For every site its different upload folder or pluging folder (wordpress). Very difficult to keep track of
[20:00] <sarnold> Sircle: Probably you could run each site under a different user account via as many FPM things as needed..
[20:04] <Sircle> hm sarnold thats the only way?
[20:07] <sarnold> Sircle: you could also use different VMs or LXD containers per site ..
[20:30] <Sircle_> sarnold,  don't I just need this? https://stackoverflow.com/a/1649731
[20:32] <sarnold> Sircle_: open_basedir is not a security tool
[20:33] <sarnold> Sircle_: even if it were, it only influences filesystem operations that go through php; ptrace, IPC, or filesystem operations that don't go through PHP aren't handled at all.
[20:33] <Sircle_> will that not limit .php files to limit to the vhost files only? <- thats what I want
[20:37] <sarnold> it will not. it's about the same as asking drivers to politely not get into accidents.
[21:44] <powersj> nacc https://jenkins.ubuntu.com/server/view/git-ubuntu/job/git-ubuntu-ci-nightly/
[21:44] <powersj> currently running the nightly job against master
[21:45] <powersj> will watch status
[21:45] <powersj> then will run a CI job if that passes
[21:56] <nacc> powersj: ack, thanks
[22:48] <nacc> rbasak: code looks good to me; you ahve one TBC in gitubuntu/apt_repo_test/README
[22:49] <rbasak> nacc: ah yes. I just need to look up the command, thanks.
[22:50] <nacc> rbasak: np
[22:51] <nacc> rbasak: and you also need a rebase :)
[23:06] <nacc> powersj: did you see the failure just now? https://jenkins.ubuntu.com/server/job/git-ubuntu-ci/303/console
[23:07] <powersj> nacc: yeah I kicked that after the nightly passed
[23:08] <powersj> I think there was a race with the nightly script also doing a vm launch
[23:14] <nacc> cpaelzer: do you think you could pick up the merge of kopanocore? i think you have more context on your delta (and if it's all been picked up by debian). I think we would normally sync, excpet we need to transition php7.1-mapi -> php-mapi