[00:40] <mup> PR snapd#8195 opened: tests/lib/prepare.sh: simplify, combine code paths <Simple 😃> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8195>
[02:26] <mup> PR snapcraft#2953 opened: meta: remove remaining `__dict__` and key list usage in snap <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2953>
[06:04] <mup> PR snapd#8189 closed: seed,cmd/snap-bootstrap: introduce seed.Snap.EssentialType, simplify bootstrap code <UC20> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8189>
[06:05] <mup> PR snapd#8183 closed: tests: remove tmp dir for snap not-test-snapd-sh on security-private-tmp test <Simple 😃> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8183>
[06:17] <mup> PR snapd#8140 closed: tests: enable more tests for UC20/UC18 <Test Robustness> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8140>
[06:19] <mup> PR snapd#8186 closed: run-checks: SKIP_GMFMT really skips formatting checks <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8186>
[06:22] <mup> PR snapd#8085 closed: [RFC] netutil: add default gateway monitor <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8085>
[06:30] <mborzecki> morning
[06:30] <mvo> mborzecki: good morning
[06:32] <mup> PR snapd#8196 opened: client: add "Resume" to DownloadOptions and new test <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8196>
[06:33] <mup> PR snapd#8188 closed: spread.yaml: make qemu ubuntu-core-20-64 use ubuntu-20.04-64 <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8188>
[06:33] <mborzecki> mvo: hey! so PRs are finally green :)
[06:35] <mvo> mborzecki: yes, it's quite nice, if we push a bit we could go below 50 today
[06:35] <mup> PR snapd#8081 closed: tests/main/user-session-env: add test verifying environment variables inside the user session <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8081>
[06:42] <mborzecki> hmm can't push an update to #8169
[06:42] <mup> PR #8169: tests/many: don't use StartLimitInterval anymore, unify snapd-failover variants, build snapd snap for UC16 tests <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8169>
[06:43] <mborzecki> looks like ian didn't tick allow edits from maintainers box
[06:45] <mvo> mborzecki: meh, a shame
[06:45] <mup> PR snapd#8195 closed: tests/lib/prepare.sh: simplify, combine code paths <Simple 😃> <Test Robustness> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8195>
[06:51] <mup> PR snapd#8197 opened: snap: refacot code in `snap download` to prepare for snap downloads <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8197>
[07:02] <mup> PR snapd#7707 closed: snap: add TestDownloadDirectStoreHappy test <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7707>
[07:32] <jamesh> could someone restart https://travis-ci.org/snapcore/snapd/builds/655225016 for me?  It looks like it failed on a timeout talking to github.com
[07:46] <mborzecki> jamesh: sure
[07:46] <jamesh> mborzecki: thanks
[07:47] <mborzecki> jamesh: looks like it's already restarted
[07:47] <zyga> Dobę
[07:47] <zyga> Done even
[07:47] <jamesh> I wonder how hard it'd be to cut Travis out of the loop completely
[07:48] <jamesh> the main feature missing from github actions is the option to make secrets available to PRs
[07:48] <zyga> jamesh: oh? Are you sure?
[07:48] <zyga> I saw secrets used in some actions I looked at
[07:49] <jamesh> zyga: yeah.  Secrets come up blank if the the job is initiated by someone without write access to the repository
[07:49] <zyga> Aaaah
[07:49] <zyga> I see
[07:49] <zyga> I guess that is only expected
[07:55] <jamesh> in contrast, anyone can submit a PR that changes .travis.yml so that their test run will exfiltrate the secrets
[08:02] <pstolowski> morning
[08:02] <mborzecki> pstolowski: hey
[08:03] <mvo> hey pstolowski
[08:03] <mvo> pstolowski: I saw some of these in travis: https://paste.ubuntu.com/p/3jdZTp7QPd/
[08:04] <mborzecki> damn serial terminals
[08:04] <pstolowski> mvo: is this with latest master?
[08:05] <mvo> pstolowski: I think so, let me double check
[08:05] <mborzecki> mvo: pstolowski: i saw this locally today when merging master to ijohnson's branch
[08:07] <pstolowski> mborzecki: ah, ok. that's annoying :(. i'll intensify my efforts on the followup then, i was hoping the last bump of the sleep time was enough as a temporary workaround
[08:08] <mvo> pstolowski: we could bump again by 1s or so
[08:08] <mvo> pstolowski: until we have the fix
[08:09] <jamesh> mvo: I noticed that, and had it happen locally.  I needed to up the wait to 3 seconds
[08:09] <jamesh> wasn't sure if it was something I'd introduced
[08:11] <mvo> jamesh: it's a recent change from pstolowski
[08:11] <mvo> jamesh: 3s each? anything unusal about your machine? particularly slow or fast?
[08:12] <pstolowski> okay, i can propose one more bump, and in the meantime will continue working on the better fix
[08:13] <jamesh> mvo: just that one test.
[08:14] <jamesh> mvo: I tried bumping in smaller increments locally, but had no idea what it was doing with the time
[08:15] <jamesh> the system is not particularly fast
[08:16] <mvo> jamesh: thank you for letting us know
[08:21] <mup> PR snapd#8198 opened: o/tests: bump TestEnsureLoopPruneAbortsOld sleep time <⚠ Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8198>
[08:25] <zyga> Sleep bump a day keeps those pesky races at bay
[08:27] <mup> PR snapd#7146 closed: [sketch] UC20: cmd/snap-verify: sketch of snap-verify <UC20> <⛔ Blocked> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7146>
[08:30] <kbroulik> Is it true Ubuntu ships chromium or chrome as Snap soon/by default or something along the lines?
[08:33] <zyga> kbroulik: dunno, is that announced somewhere?
[08:34] <kbroulik> https://snapcraft.io/blog/chromium-in-ubuntu-deb-to-snap-transition I think this
[08:35] <zyga> This seems like a deb is migrating to a snap, is that what you meant?
[08:35] <kbroulik> yeah, sorry, my wording wasn't clear
[08:35] <zyga> That is not the same as ship by default (preinstall)
[08:35] <kbroulik> "is it true Ubuntu ships chromium as a snap instead of a deb?" :)
[08:35] <kbroulik> right
[08:36] <zyga> Given that post it would seem so
[08:36] <kbroulik> hm maybe I should try it first and see if it breaks my project :)
[08:48] <mup> PR snapd#8199 opened: tests: enable snapd-failover on uc20 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8199>
[08:52] <mvo> mborzecki: for your recovery-chooser pr - you need to install it in the debian packaging to some place
[08:52] <mvo> mborzecki: check e.g. debian/snapd.install
[08:53] <mborzecki> mvo: it's already added there
[08:53] <mborzecki> hmmm
[08:53] <mborzecki> uhh 14.04
[08:55] <mvo> mborzecki: was just looking over the recent failure in spread, not really looking closely
[08:56] <kbroulik> ok so yeah I tried chromium snap and as I feared: it breaks plasma-browser-integration as it cannot find the native host :/
[08:59] <kbroulik> interestingly it does have a whitelist for /etc/chromium which should allow this
[09:06] <kbroulik> ah. ok, so chromium snap also breaks gnome chrome shell. so the whitelist doesnt actually work
[09:06] <kbroulik> https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1741074 ok, is known. thanks anyway :)
[09:06] <mup> Bug #1741074: [snap] chrome-gnome-shell extension fails to detect native host connector <snap> <chromium-browser (Ubuntu):Triaged> <https://launchpad.net/bugs/1741074>
[09:41] <zyga> mvo: I wonder if master will be red by Friday
[09:44] <mvo> zyga: mh, why?
[09:45] <mvo> zyga: it looks mostly green right now
[09:45] <zyga> mvo: that prune thing
[09:45] <zyga> mvo: feels like a deeper problem
[09:47] <mvo> zyga: no worries, pawel is working on a better version of this test
[10:17] <mup> PR snapd#8200 opened: [RFC] cmd/snap-chooser-ui-demo: a demo of recovery chooser UI <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8200>
[10:17] <pedronis> zyga: #7219 was force pushed a bunch of times, that is not great
[10:17] <mborzecki> mvo: the UI demo bit ^^
[10:17] <mup> PR #7219: devicestate/firstboot: check for missing bases early <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7219>
[10:18] <pedronis> heh, I meant #7129
[10:18] <mup> PR #7129: userd: allow setting default-url-scheme-handler <⛔ Blocked> <Created by jwheare> <https://github.com/snapcore/snapd/pull/7129>
[10:18] <jwheare> unfortunately rebasing onto master was required and that requires a force
[10:18] <jwheare> this has been open a looong time heh
[10:18] <zyga> pedronis: yeah, I noticed, I just +1 the fact that the contributor has not lost interest
[10:19] <pedronis> jwheare: well, it means now it needs a review by me, even it got a lot of +1s already
[10:19] <zyga> it looks like the entire history is kept, just rebased
[10:19] <mborzecki> damn, github ui popup when you start entering #<PRnumber> is so confusing and buggy
[10:20] <zyga> pedronis: can you delegate that review to others?
[10:20] <pedronis> zyga: maybe
[10:20] <pedronis> I still need to understand what the PR does either way
[10:20] <pedronis> I planned to do that in any case
[10:21] <jwheare> also, as was mentioned in the comments, i was iterating yesterday just to force sloow test reruns, often including white space changes, which were useless. during that time there were some comments before i had finished, and i squashed at the end. the squashed part is clearly marked out
[10:22] <zyga> I had a look at this originally, the key is the {Check,Get,Set}Sub API - it's a part of the xdg-settings system https://portland.freedesktop.org/doc/xdg-settings.html
[10:22] <zyga> the rest is glue to our stack
[10:22] <zyga> pedronis: ^
[10:22] <pedronis> I marked it for me, hopefully I can decide something about it still this week
[10:24] <zyga> pedronis: perhaps github UI has improved as the rebase did not break the flow of the comments
[10:24] <pedronis> it seems it has
[10:29] <pedronis> zyga: also it should probably not go in 2.44, we are too close to wanting to cut it
[10:29] <pedronis> and it's already full of things
[10:29] <mborzecki> yeah, the comments stay and are marked as outdated, you can also click on the rebase change and see the diff
[10:30] <mvo> mborzecki: nice!
[10:31] <zyga> pedronis: it's not my decision, I would probably let it in as it's been there for a while and I'm not sure how getting it in at the next cycle will help - it probably won't be tested by anyone apart from the currently, single user interested in it (as in single snap)
[10:31] <mborzecki> time to put all the recover bits back together again
[10:31] <pedronis> zyga: if nothing else it changes spread tests, that's reason enough not to merge just before cutting
[10:32] <mup> PR snapd#8194 closed: o/devicestate: unset recovery_system when done seeding <Simple 😃> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8194>
[10:41] <pedronis> zyga: I looked a bit, there are actually issues with the code
[10:42] <zyga> pedronis: I'll check your review
[10:42] <pedronis> zyga: I haven't reviewe, I'm just skimming, but saw a place where it could panic for example
[10:44] <zyga> pedronis: on SplitN?
[10:44] <pedronis> yes for example
[10:44] <pedronis> also why the cast to string
[10:46] <zyga> on checkOutput? bytes / strings
[10:46] <jwheare> that was in the original code
[10:46] <pedronis> no, there's SplitN(string(thing)...  but thing is already a string
[10:46] <pedronis> anyway it needs clearly another review pass and checking for coverage
[10:46] <pedronis> sorry
[10:47] <jwheare> https://github.com/snapcore/snapd/blob/master/usersession/userd/settings.go#L168
[10:50] <mup> PR snapd#8201 opened: [WIP,RFC] Mock prune ticker in overlord tests to reduce wait times <Created by stolowski> <https://github.com/snapcore/snapd/pull/8201>
[10:52] <pedronis> jwheare: different assumptions, but yes that code is fragile too, but that code doesn't even assume there's a path wher the 2nd part is not there
[10:53] <jwheare> probably down to me copy/pasting existing code to a different place. well spotted
[10:53] <pedronis> the string bit is needed because output is []byte there
[10:53] <jwheare> yeah
[10:54]  * zyga straces systemd-run to see why it hangs
[10:54] <zyga> good old 18.04
[10:54] <zyga> everything works
[10:54] <pedronis> anyway, I'll try to give this some attention still this week (next week we are at a sprint), but no promises, my own queue is long atm
[10:54] <zyga> extend tests to all systems
[10:54] <zyga> 16.04 shows it's rusty fangs
[10:55] <jwheare> pedronis: there is no rush, more eyes are always good
[10:55] <jwheare> i have to say i lost a lot of time to that "not" command
[10:56] <jwheare> "why is this erroring when i test this on some dummy bash code locally"
[10:57] <jwheare> also trying to work out what's happening in failing tests that check stderr output by redirecting to a file when set -x prints to stderr too is fun
[10:58] <mup> PR snapd#8202 opened: cmd/snap-bootstrap,seed: verify only in-play snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/8202>
[10:58] <jwheare> 90% of this PR was probably test wrangling heh
[10:59] <pedronis> mvo: mborzecki: #8202 should speed up snap-bootstrap a bit
[10:59] <mup> PR #8202: cmd/snap-bootstrap,seed: verify only in-play snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/8202>
[11:04] <zyga> so I guess I have a solution for the systemd-run getting stuck
[11:04] <zyga> it changes the usability a little but not by much, at least for testing
[11:05] <pedronis> pstolowski: hi, should I look at #8201, or not yet?
[11:05] <mup> PR #8201: [WIP,RFC] Mock prune ticker in overlord tests to reduce wait times <Created by stolowski> <https://github.com/snapcore/snapd/pull/8201>
[11:05] <pstolowski> pedronis: let's see if it passes first, i'll re-run it a few times
[11:06] <pedronis> ok
[11:08] <mvo> fun on arm64 it seems http://paste.ubuntu.com/p/Q7CMcqRK5T
[11:08]  * mvo retries the ppa build where this happend
[11:09] <zyga> mvo: that's the new stopper code?
[11:09] <pedronis> yes
[11:09] <mvo> yes
[11:10] <zyga> maybe want to see my simple epoll code instead
[11:10] <zyga> though it's kind of close to release
[11:10] <zyga> so dunno
[11:10] <mvo> lookng now
[11:10] <zyga> maybe just more locking / if nil things
[11:13] <mvo> zyga: yeah, looks like the timeout is nil for some reason
[11:14] <mborzecki> pedronis: cool, let me take a look
[11:16] <mup> PR snapd#8192 closed: tests: add more debug output to the snapd-failure handling <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8192>
[11:17] <ijohnson> mborzecki sorry not sure why the box wasn't ticked on 8169 but it should be good now
[11:18] <mborzecki> ijohnson: cool, let me merge again and push
[11:18] <pedronis> mvo: ah, you cannot pass nil for timeout on arm64
[11:19] <mvo> pedronis: interessting, shall I push a fix or will you?
[11:19] <mvo> pedronis: breaks the arm64 builds right now
[11:20] <pedronis> mvo: yes, but it's a bit unclear what the fix should be, null means don't timeout
[11:21] <pedronis> 0 means don't even try
[11:23] <pedronis> mvo: this is fixed in newer versions of go :/
[11:23] <mvo> pedronis: oh no
[11:23] <mvo> pedronis: we could workaround with timeout.Sec: 999999
[11:24] <zyga> mvo: perhaps the man page is relevant
[11:24] <mvo> pedronis: fugly but would probably be ok?
[11:24] <zyga> I didn't read the code so not sure if that's the culprit
[11:24] <zyga> https://www.irccloud.com/pastebin/zFnzXT9r/
[11:24] <pedronis> mvo: we probably should workaround but setting everything to the max but only on arm64
[11:24] <mvo> pedronis: +1
[11:24] <mvo> pedronis: I can prepare a PR
[11:24] <pedronis> zyga: the panic points to a place and the place is reading timeout
[11:25] <ijohnson> mborzecki did you see my typo in the PR too? Seems the spread tests didn't run due to my typo in that PR
[11:25] <pedronis> it's fixed in newer go
[11:25] <zyga> pedronis: I see
[11:25] <pedronis> see the if at line 90 here: https://golang.org/src/syscall/syscall_linux_arm64.go
[11:25] <pedronis> older go don't have it
[11:25]  * pedronis lunch
[11:26] <zyga> uh, I see
[11:26] <zyga> sucks, bug in the wrapper
[11:26] <mvo> yep
[11:27] <mborzecki> ijohnson: yeah, i'm looking and shellcheck, it's unhappy about some things, also one of the warnings looks like a bug in shellcheck ;)
[11:28] <ijohnson> :-(
[11:29] <mborzecki> ijohnson: hahah https://paste.ubuntu.com/p/yb6d9NMN3B/
[11:30] <ijohnson> Ahh
[11:44] <mup> PR snapd#8203 opened: netlink: fix panic on arm64 with the new rawsockstop code <Created by mvo5> <https://github.com/snapcore/snapd/pull/8203>
[11:45] <pedronis> mvo: in theory if we timeout the subsquent read will give us EWOULDBLOCK or similar and we retry, so just having some kind of long timeout should work
[11:46] <pedronis> mvo: not sure if we can test somehow that scenario though
[11:46] <mvo> pedronis: I pushed the workaround with int64 seconds timeout
[11:48] <mborzecki> ijohnson: pushed
[11:48] <mvo> pedronis: it's enough time I think, still worth double checking if select behaves sanely for such a huge value
[11:49] <pedronis> mvo: or we don't make it huge but as I said check that the udev code does the right thing if select timeouts
[11:49] <pedronis> it should (in theory)
[11:50] <mvo> pedronis: I have no strong opinion either way, I pushed the simplest thing but I can iterate on this
[11:51] <mborzecki> ijohnson: i should probably file an issue with shellcheck about the for loop
[11:57]  * zyga stops banging the head against the wall and breaks for a quick snack
[12:00] <mup> PR snapd#8204 opened: data/systemd: improve the description <Created by sergiusens> <https://github.com/snapcore/snapd/pull/8204>
[12:04] <pedronis> mvo: I'll try something test-wise on top of your PR in a bit
[12:05] <mvo> pedronis: sure
[12:07] <mborzecki> ijohnson: https://github.com/koalaman/shellcheck/issues/1847 heh
[12:07] <zyga> back
[12:08] <mborzecki> ijohnson: wouldn't be surprised if _ is an actual variable getting assigned to at this point
[12:08] <zyga> mborzecki: what were you expecting?
[12:08] <zyga> oh
[12:08] <zyga> actually
[12:08] <mborzecki> zyga: nothing ;)
[12:08] <zyga> I'm surprised now
[12:08] <zyga> mborzecki: bash and dash disagree
[12:08] <zyga> mborzecki: _ is ok in dash
[12:08] <zyga> mborzecki: and a no-op in bash
[12:09] <zyga> I suspect it is documented somewhere
[12:10] <mborzecki> zyga: fwiw it's flagged for -s bash too
[12:40] <pedronis> mvo: not for 2.44 but we should consider using x/sys/unix for a our few syscall needs maybe
[12:43] <pedronis> mvo: there's a missing import in _other.go
[12:51] <mup> PR snapd#8199 closed: tests: enable snapd-failover on uc20 <Simple 😃> <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8199>
[12:55] <jwheare> pedronis: probably worth mentioning the force push thing in the contribution guide btw, since different projects have different norms https://github.com/snapcore/snapd/blob/master/CONTRIBUTING.md
[13:04] <zyga> wl
[13:04] <zyga> sorry,
[13:04] <zyga> thunder :)
[13:04] <zyga> winter is over
[13:07] <zyga> and hail
[13:08] <pedronis> mvo: pstolowski: I pushed a fix and one more test (at the cost of some changes) to #8203
[13:08] <mup> PR #8203: netlink: fix panic on arm64 with the new rawsockstop code <Created by mvo5> <https://github.com/snapcore/snapd/pull/8203>
[13:09] <pstolowski> pedronis: ok, will rereview
[13:10]  * pstolowski lunch
[13:11] <pstolowski> zyga: nb, #8170 is ready for re-review
[13:11] <zyga> ack
[13:11] <mup> PR #8170: snap-preseed: support for preseeding of snapd and core18 <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8170>
[13:11] <zyga> looking
[13:11] <pstolowski> ty
[13:14] <mborzecki> heh, last minute changes are always a bad idead
[13:16] <zyga> mborzecki: what did you break?
[13:16] <zyga> ;)
[13:17] <mborzecki> zyga: heh little tweaks in the ui before opening the PR
[13:17] <mborzecki> ofc unit tests are passing ;)
[13:33] <mup> PR snapd#8196 closed: client: add "Resume" to DownloadOptions and new test <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8196>
[13:55] <zyga> pstolowski: reviewed
[13:56] <pstolowski> zyga: thanks!
[13:56] <zyga> pstolowski: thank you, I just did the last review :)
[14:37] <mup> PR snapd#8205 opened: tests: just remove user when the system is not managed on create-user-2 test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8205>
[14:41] <zyga> pstolowski: we should bring barylki
[14:41] <zyga> they will function both as sweets
[14:41] <zyga> hand sanitizers
[14:41] <zyga> and throat sanitizers
[14:42] <mup> PR snapd#8204 closed: data/systemd: improve the description <Simple 😃> <Skip spread> <Created by sergiusens> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8204>
[14:42] <zyga> I'll take a break to take the dog out
[14:42] <zyga> brb
[14:45] <pedronis> mvo: it's a minor thing but it might make sense to backport 8204 to 2.44 if it's what is going into 20.04
[14:45] <pedronis> and is not too annoying
[14:45] <mvo> pedronis: +1
[14:47] <mup> PR snapd#8206 opened: travis.yml: run unit tests on arm64 as well <Created by mvo5> <https://github.com/snapcore/snapd/pull/8206>
[14:50] <pstolowski> zyga: i'm actually thinking about some 'stronger' sweets this time ;)
[14:53] <mborzecki> mvo: for the race with mount units: https://paste.ubuntu.com/p/z7ZpDRmKcW/
[14:54] <zyga> back
[14:54] <zyga> my phone just got an ... ubuntu touch update
[14:54] <mvo> mborzecki: oh, nice!
[14:55] <zyga> yeah
[14:59] <pstolowski> zyga: woot!?
[14:59] <pstolowski> ubuports?
[15:01] <zyga> yes
[15:01] <zyga> booting now
[15:05] <zyga> pstolowski: heh, there's a new UI
[15:06]  * cachio lunch
[15:13] <ijohnson> mborzecki: hmm seems the merge went a bit awry on 8169, okay if I push up some changes or are you working on it ?
[15:17] <pstolowski> zyga: show me a screenshot pls
[15:18] <zyga> how do I make screenshots on core
[15:18] <zyga> er
[15:18] <zyga> phone
[15:20] <zyga> it's pretty, I"ll bring it
[15:20] <zyga> you'll see :)
[15:20] <zyga> back to services
[15:23] <ijohnson> mborzecki: well I'll just push anyways
[15:30] <pedronis> zyga: mvo: at this point #7825 targets 2.45, right?
[15:30] <mup> PR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
[15:31] <zyga> pedronis: yes
[15:31] <zyga> pedronis: there's one real issue that needs fixing
[15:31] <zyga> pedronis: and tests to cover it
[15:31] <pedronis> it's fine, changing the milestone
[15:31] <zyga> pedronis: it's not critical (not desktop) but needs to be debugged all the way because it's critical path
[15:31] <mvo> pedronis: +1
[15:32] <mborzecki> ijohnson: yeah, please do, there were 2 merges, both had conflicts because of related things landing
[15:33] <ijohnson> mborzecki: ack
[15:46] <ijohnson> pedronis: I reviewed your essential snaps PR, thanks for that
[15:46] <ijohnson> pedronis: if you could quick take a look at my question on https://github.com/snapcore/snapd/pull/8185#issuecomment-591193478 that would be appreciated thanks
[15:46] <mup> PR #8185: tests: add uc20 kernel snap upgrade managers test, fix bootloadertest bugs <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8185>
[15:50] <pedronis> ijohnson: thank you
[15:50] <pedronis> ijohnson: looking (was having a different chat somewhere else)
[15:50] <ijohnson> pstolowski: should I re-review #8170, seems to have changed a bit since I last reviewed
[15:50] <mup> PR #8170: snap-preseed: support for preseeding of snapd and core18 <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8170>
[15:50] <ijohnson> pedronis: thanks
[15:51] <pedronis> ijohnson: ah, that, we always keep 2 or 3 older revisions per snap, so it's normal that the unpacked assets for them would stay around, you need to install 4 kernels before you see assets go away I think
[15:51] <pedronis> keep 2 or 3 XoldX revisions
[15:51] <ijohnson> pedronis: ok, not sure if we wanted to keep the assets around on ubuntu-boot
[15:52] <ijohnson> looks like the unit test is correct then and I'll just remove that last check
[15:52] <pedronis> ijohnson: that's the logic as is right now, we might want to change it but needs a larger discussion
[15:52] <pstolowski> ijohnson: i think the changes are very small, not necessary
[15:52] <ijohnson> pstolowski: ok thanks for confirming
[15:53] <pstolowski> ijohnson: np, thanks for asking!
[15:54] <pedronis> ijohnson: that's what we do on uboot devices atm for UC16 UC18
[15:54] <ijohnson> pedronis: makes sense. today I will work on cross-checking the signing keys in the kernel.efi we booted with in snap-bootstrap vs the ones in the current_kernels kernel snaps and open the other boot robustness PR then
[15:55] <pedronis> thx
[15:55] <pedronis> ijohnson: ping me if you need input on something
[15:55] <ijohnson> sure
[16:06] <zyga> I'll grab some food, family's back
[16:15] <pedronis> pstolowski: I reviewed #8190, looks like what I expected, some comments on details
[16:15] <mup> PR #8190: overlord, taskrunner: exit on task/ensure error when preseeding <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8190>
[16:15] <pstolowski> pedronis: thanks! i forgot about state lock
[16:16] <pstolowski> pedronis: nb #8170 is probably close if you can re-review
[16:16] <mup> PR #8170: snap-preseed: support for preseeding of snapd and core18 <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8170>
[16:18] <pedronis> pstolowski: I don't think #8170 needs a review by me, I think you address my main point, right?
[16:18] <mup> PR #8170: snap-preseed: support for preseeding of snapd and core18 <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8170>
[16:18] <pedronis> *addressed
[16:18] <pstolowski> pedronis: that's fine, i wasn't sure if that was all. thanks
[16:19] <pedronis> pstolowski: actually, I am a bit confused, I thought preseeding worked with core 16 ?
[16:19] <pedronis> it seems you are blocking that too?
[16:19] <pedronis> or am I misreading the code
[16:19] <pedronis> or are you being careful because there is not spread test yet?
[16:23] <pedronis> pstolowski: to be clear I'm fine, we don't have a strong use case for core atm, especially core 16, just trying to understand
[16:26] <pstolowski> pedronis: my intent was to allow only classic with core snap or core18+snapd, and consider core systems in followups (with tests)
[16:26] <pedronis> pstolowski: ok, that's fine
[17:08] <cmatsuoka> cachio: what was the name of the sb/tpm enabled image again?
[17:10] <cachio> cmatsuoka, google-tpm is the server
[17:10] <cachio> backend
[17:10] <cmatsuoka> ah ok, let me try that... thanks!
[17:10] <cachio> cmatsuoka, https://github.com/snapcore/snapd/blob/master/spread.yaml#L128
[17:11] <cachio> you should try something like google-tpm:ubuntu-20.04-64:
[17:12] <cachio> cmatsuoka, you are the first one using those images
[17:12] <cachio> cmatsuoka, please tell me if you need any change
[17:18] <ijohnson> pstolowski: what's the first release that hotplug worked on ? 2.42 ?
[17:19] <pstolowski> ijohnson: hmm, tough question, i need to dig a bit, one moment
[17:19] <ijohnson> thanks
[17:19] <mup> PR snapcraft#2952 closed: spread: introduce appstream parse-info test <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2952>
[17:22] <pstolowski> ijohnson: 2.39 it seems
[17:23] <ijohnson> thanks pstolowski
[17:23] <pstolowski> ijohnson: based on https://forum.snapcraft.io/t/hotplug-implementation-plan/4554/3 cause debian changelog wasn't too helpful
[17:23] <ijohnson> pstolowski: degville: I made a small edit to https://forum.snapcraft.io/t/hotplug-support/10750 to reflect that snapd edge isn't useful anymore
[17:23] <ijohnson> err rather isn't needed anymore for enabling hotplug
[17:24] <degville> ijohnson: thank you!
[17:26] <pstolowski> ijohnson: thanks, makes sense
[19:23] <pedronis> mvo: are you building a new 2.43 ?
[19:24] <pedronis> of snapd
[20:31] <zyga> mvo, pedronis: snapd is held up in store review
[20:31] <zyga> types: New type "application" does not match the type of the latest approved revision, r6625 ("snapd")
[20:32] <pedronis> zyga: that's a 2.43 build, that's why I asked mvo
[20:32] <zyga> I see
[20:50] <mvo> pedronis: no plan to re-build 2.43, cherry picked one commit though in this branch just in case, I think we can ignore this
[20:54] <mvo> uh, looks like master is red - is that because of "tests/main/retry-network" failing?
[20:57] <mvo> looks like it - oh well
[20:57] <mvo> something for my morning I guess
[21:06] <pedronis> mvo: yes, something strange going on with retry-network
[21:07] <pedronis> lots of red
[21:07] <pedronis> not just master
[21:11] <cachio> pedronis, I am testing a fix for the retry-network
[21:11] <cachio> it is a timing issue
[21:24] <ijohnson> cachio: what's the timing issue for retry-network?
[21:29] <cachio> ijohnson, takes some time to NoNetwork: true
[21:29] <ijohnson> cachio: ah as in the network namespace isn't created immediately?
[21:30] <cachio> in the output file I see NoNetwork: false
[21:30] <cachio> but after a time it appears NoNetwork: true
[21:33] <cachio> ijohnson, I am testing the fix right now
[21:34] <ijohnson> cachio: cool let me know when/if you want me to review
[21:34] <cachio> ijohnson, sure, thanks!!
[21:49] <cachio> there are 2 problems
[21:49] <cachio> timing issue
[21:49] <cachio> which is fixed
[21:49] <cachio> also getent hosts www.ubuntu.com is returning the ipv6 instead of the ip
[21:49] <cachio> todya I updated the images
[21:50] <cachio> I think there was a change in a package which is affecting this
[21:51] <cachio> ijohnson, ~
[21:51] <ijohnson> cachio: ah I see yeah ipv6 could break things I suppose
[21:52] <ijohnson> cachio: I need to step out for a while, but feel free to request my review, I'll be back in a hour or two
[21:52] <cachio> ijohnson, sure, np
[22:17] <mup> PR snapd#8207 opened: tests: fix retry network test after image update <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8207>
[22:41]  * cachio afk


[03:26] <nacc> cjwatson: fair enough :)
[15:09] <teward> cjwatson: well i've got tsimonq2 being adamant "But the regex is verbatim and i'm not changing it because that's what the system says"
[15:09] <teward> whereas some of my python checkers are complaining :p
[15:09] <teward> wasn't sure if it was critical or not.
[15:09] <teward> nacc: not if you pass the pattern as a raw string - r"pattern#goes#here" apparently.
[15:10] <cjwatson> This is really not critical
[15:10] <cjwatson> Remove the backslash or not, I don't care
[15:11] <teward> yep, i was just being overly complaining because i was reviewing one of Lubuntu's irc bots' code as a favor :)
[15:11] <teward> no problem.  *goes back to working on things*
[15:11] <cjwatson> And it has nothing to do with whether the pattern is passed as a raw string
[15:12] <cjwatson> Comment support is controlled by the re.X == re.VERBOSE flag
[15:12] <cjwatson> If anyone wants the regex to change, they can propose an MP changing it in lib/lp/soyuz/enums.py
[15:13] <cjwatson> I've got no problem with that but won't be spending my own time on it
[15:13] <tsimonq2> teward: Do that before messing with Lubuntu's regex. :P
[15:17] <teward> cjwatson: do we enable re.X though?  I thought we didn't enable that?
[15:17] <teward> *drags tsimonq2 through the mud anyways*
[15:19] <teward> because it looks to me we don't enable re.X in enums.py :P
[15:19] <teward> (and I prefer NOT having that enabled unless necessary lol)
[15:19] <cjwatson> We do not
[15:19] <cjwatson> I wasn't saying we did
[15:20] <teward> i'm not awake yet heh :P
[15:20] <teward> but that answers the question :)
[15:20] <cjwatson> Just that that's what governs whether # introduces a comment, not whether the pattern is passed as a raw string
[15:20] <teward> *goes for more coffee*
[15:20] <teward> ah I see


[16:04] <GunnarHj> popey: Hi Alan! Saw your mail, now would be fine for me.
[16:05] <popey> heya
[16:11] <popey> have pm'ed you GunnarHj :)
[16:12] <GunnarHj> popey: pm'ed... Where?
[16:12] <popey> here on irc :)


[14:37] <brlin> Hello, I would like to ask whether the CVE-2023-6546 vulnerability has been dealt with in the Ubuntu kernels?  I unable to locate notices about it in the USN.
[14:38] -ubottu:#ubuntu-security- A race condition was found in the GSM 0710 tty multiplexor in the Linux kernel. This issue occurs when two threads execute the GSMIOC_SETCONF ioctl on the same tty file descriptor with the gsm line discipline enabled, and can lead to a use-after-free problem on a struct gsm_dlci while restarting the gsm mux. This could allow a local unprivileged user to escalate the... <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-6546>
[14:38]  * brlin Good bot (pats).
[14:39] <brlin> Additional info: https://github.com/YuriiCrimson/ExploitGSM (There seems to be a conflict of who is the original author of the PoC, though it's not really our businesses.)
[14:45] <tomreyn> https://ubuntu.com/security/CVE-2023-6546
[14:45] -ubottu:#ubuntu-security- A race condition was found in the GSM 0710 tty multiplexor in the Linux kernel. This issue occurs when two threads execute the GSMIOC_SETCONF ioctl on the same tty file descriptor with the gsm line discipline enabled, and can lead to a use-after-free problem on a struct gsm_dlci while restarting the gsm mux. This could allow a local unprivileged user to escalate the... <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-6546>
[14:47] <tomreyn> (i'm not sure that the exploit you posted is mitigated by the existing fix.)
[14:48] <tomreyn> and i'm not speaking for ubuntu or the security team
[14:54] <brlin> tomreyn: Thanks for the information!  I'll check it out.
[15:09] <sbeattie> brlin: assuming that CVE-2023-6546 is the fix for what is being exploited above, yes, it has been addressed in ubuntu kernels
[15:09] -ubottu:#ubuntu-security- A race condition was found in the GSM 0710 tty multiplexor in the Linux kernel. This issue occurs when two threads execute the GSMIOC_SETCONF ioctl on the same tty file descriptor with the gsm line discipline enabled, and can lead to a use-after-free problem on a struct gsm_dlci while restarting the gsm mux. This could allow a local unprivileged user to escalate the... <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-6546>
[15:10] <brlin> sbeattie: Thanks for the information mOwOm.
[15:13] <sbeattie> brlin: oh, boo, the initial fix for CVE-2023-6546 got reverted upstream: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=29346e217b8ab8a52889b88f00b268278d6b7668
[15:13] -ubottu:#ubuntu-security- Commit 29346e2 in kernel/git/torvalds/linux.git "Revert 'tty: n_gsm: fix UAF in gsm_cleanup_mux'"
[15:13] -ubottu:#ubuntu-security- A race condition was found in the GSM 0710 tty multiplexor in the Linux kernel. This issue occurs when two threads execute the GSMIOC_SETCONF ioctl on the same tty file descriptor with the gsm line discipline enabled, and can lead to a use-after-free problem on a struct gsm_dlci while restarting the gsm mux. This could allow a local unprivileged user to escalate the... <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-6546>
[15:14] <brlin> sbeattie: That's...interesting.
[15:16] <brlin> Though the upstream should have a following patch to fix the vulnerability, right?
[15:19] <sbeattie> brlin: sorry, I'm confusing myself by doing this without enough coffee.
[15:20] <sbeattie> brlin: the fix for CVE-2023-6546, 3c4f8333b582 ("tty: n_gsm: fix the UAF caused by race condition in gsm_cleanup_mux"), was not reverted.
[15:20] -ubottu:#ubuntu-security- A race condition was found in the GSM 0710 tty multiplexor in the Linux kernel. This issue occurs when two threads execute the GSMIOC_SETCONF ioctl on the same tty file descriptor with the gsm line discipline enabled, and can lead to a use-after-free problem on a struct gsm_dlci while restarting the gsm mux. This could allow a local unprivileged user to escalate the... <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-6546>
[15:21] <brlin> sbeattie: No worries.  Thanks for the confirmation, BTW.
[15:22] <sbeattie> but that commit references fixing 9b9c8195f3f0 ("tty: n_gsm: fix UAF in gsm_cleanup_mux") which is also what got reverted in 29346e217b8ab8a52889b88f00b268278d6b7668 linked above
[15:23]  * brlin Probably will try the PoC on a fresh cloud VM just to see if it works.
[15:23] <sbeattie> so while I think CVE-2023-6546 in isolation may be "fixed" there are still other UAFs in the n_gsm.c code, the root cause explained by the revert commit
[15:23] -ubottu:#ubuntu-security- A race condition was found in the GSM 0710 tty multiplexor in the Linux kernel. This issue occurs when two threads execute the GSMIOC_SETCONF ioctl on the same tty file descriptor with the gsm line discipline enabled, and can lead to a use-after-free problem on a struct gsm_dlci while restarting the gsm mux. This could allow a local unprivileged user to escalate the... <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-6546>
[15:24] <brlin> Thanks for the analysis.
[15:24] <sbeattie> bah, the bot needs a silence cache, to not report the same CVE id in the space of a few minutes.
[15:24]  * brlin lmao
[15:26] <sbeattie> The english writeup at https://jmpeax.dev/The-tale-of-a-GSM-Kernel-LPE.html has a screenshot at the end of running the exploit on ubuntu against a 6.5.0-25 ubuntu kernel; if not doctored (I don't think it is, but you never know), that kernel has the commit  3c4f8333b582 ("tty: n_gsm: fix the UAF caused by race condition in gsm_cleanup_mux"
[15:33] <sbeattie> looking through the commit history for n_gsm.c, I'm not seeing anything that would fix that, but that's based on a quick perusal.
[15:36] <sbeattie> Thanks for raising the issue.
[15:55] <brlin> sbeattie: No problem.
[18:27] <brlin> sbeattie: I'd like to inform you that I am able to reproduce the vulnerability on a GCP Compute Engine instance running `6.5.0-27-generic` Ubuntu kernel(the GCP kernel doesn't seemed to be vulnerable as the n_gsm module doesn't seem to be built).  The first invocation of the PoC code stuck at the `waiting setconf dlci thread` stage, but the second invocation get me a root shell.  This is reproduced using the 2e87080 revision of the PoC.
[18:29]  * brlin Thinks as the PoC is already in the wild, there's probably no reason to discuss it in private, but do inform me if I'm wrong.
[18:33] <sbeattie> brlin: thanks for reproducing, I agree, the writeups are public, so no sense trying to keep it private
[18:34] <brlin> Note that the OffsetGenerater program in the PoC code must first be run (as root, but possibly can be done in another host with the same kernel) to generate the data that needs to be inserted in the `kernels_offsets` array of the PoC code(~line 370).  I'll leave the matter to you :D.
[19:32] <sbeattie> brlin: FYI https://lore.kernel.org/stable/2024041054-asleep-replace-96e8@gregkh/T/#m3a8ce43359ad57e447faa4db6ecf4f4c1b60c498
[19:41] <brlin> sbeattie: Thanks for the information!


[20:38] <astraljava> That's highly regularly compared to one who has done it nonce in 14 years (or so). :D
[22:53] <JackFrost> What can I say?  I'm a sucker for the season. :3


[12:33] <renl> anyone noticed for ubuntu on arm computers, attempting to read from 2 ttyACM devices will hang the system and create a kernel panic?
[12:33] <renl> basically it will overwhelm the cpu with software interrupts
[12:36] <renl> in this case the computer is an asus tinker board
[12:38] <renl> i tried the Armbian ubuntu which is on kernel version 4.13.16 and the ubuntu image from elar system on kernel version 4.4.71 both has this issue
[12:38] <renl> when i tried using debian stretch on kernel 4.4.71 for the board it does not have this problem
[12:38] <renl> appears to be a problem only on ubuntu
[12:58] <y0sh> renl: how do you like your tinkerboard
[13:01] <renl> in general?
[13:01] <y0sh> yes
[13:01] <renl> its pretty ok, i am trying to run ROS on it
[13:02] <renl> lots of cpu power for my purposes so its good
[13:02] <renl> but im now stumped on what to me appears to be some driver bugs? on cdc_acm or something
[13:02] <renl> ttyUSB is ok, ttyACM kills the os
[13:03] <y0sh> yes i am running the tinkeros seams to be ok. I havent done anything but get it running and now it just sits would like a better os for it
[13:04] <renl> tinkeros does not have that ttyACM issue
[13:05] <renl> too bad ROS doesnt have support for debian on armhf :(
[13:06] <y0sh> maybe one day it will have a better selection of os's to choose from like the rpi
[13:07] <renl> i wonder if rpi has this issue of hanging the system when reading multiple ttyACMs
[13:07] <y0sh> not sure havent tried


[00:26] <viperZ28> are there any customer stories for Juju in the market place?
[00:28] <viperZ28> does Canonical know who is currently using the product, to what degree and what type of infrastructure they are deployed to?
[00:29] <marcoceppi_> viperZ28: There are quite a few enterprise customers of Canonical using Juju, I'm not sure if we have any user/customer stories
[00:29] <marcoceppi_> viperZ28: there's a white paper on using Juju and MaaS from a company somewhere
[00:29] <viperZ28> who is your west coast contact?
[00:29] <marcoceppi_> http://en.community.dell.com/techcenter/extras/m/white_papers/20437770.aspx
[00:29] <marcoceppi_> viperZ28: for what?
[00:29] <viperZ28> sales, support, etc
[00:30] <marcoceppi_> viperZ28: uh, I don't know. Let me find out for you
[00:31] <viperZ28> ok, we may already have it I will ping around as well.
[00:34] <marcoceppi_> viperZ28: I mean, Juju itself and the charms are all open source
[00:34] <marcoceppi_> but if you were looking for Canonical support for stuff, I'm still finding that person
[00:35] <arosales> viperZ28: hello
[00:37] <arosales> viperZ28: depnding at where you are at in the process you can fill out http://www.canonical.com/services/contact-us
[00:39] <arosales> viperZ28: if you comfortable you can private message me your email and I would be happy to hook you into some sales contacts at Canonical.
[07:40] <onrea> I got an error when I was installing Discourse on my local machin: ERROR cannot get latest charm revision: charm not found: cs:precise/discourse
[07:41] <onrea> I could not find Discourse in repositories: https://github.com/charms/?query=
[07:43] <onrea> lazyPower: Because of a limitation for new user on discourse.ubuntu (-> just 3 posts in one topic), I continued the topic here: http://askubuntu.com/q/431218/152405
[08:02] <onrea> ERROR cannot get latest charm revision: charm not found in "/home/onrea/charms": local:precise/discourse
[08:02] <onrea> how to solve that
[08:04] <onrea> I clined github.com/discourse/discourse in ~/charms and I got this warning: failed to load charm at "/home/onrea/charms/precise/discourse": metadata.yaml: no such file or directory
[08:04] <onrea> then that ERROR occurred again.
[08:04] <onrea> cloned*
[08:59] <onrea> Why I get this error: http://paste.ubuntu.com/7054706/ when I run `juju status`?
[10:12] <onrea> Why I get this error when I try for `juju status`: “lxc-create”: + ''[''
[10:13] <onrea> full errer: http://paste.ubuntu.com/7054706/
[10:13] <onrea> Is it solvable?
[10:20] <onrea> Is there any irc channel for  http://lists.linuxcontainers.org/listinfo/lxc-users ?
[13:59] <onrea> Why I get the below error when I run juju status?
[13:59] <onrea> agent-state-info: '(error: error executing "lxc-create": + ''['' amd64 == i686
[13:59] <onrea> ...
[14:02] <lazyPower> onrea: o/
[14:04] <onrea> It's a full day to try install different software via juju but I get that dummy error! I'm tired. It killed me!
[14:05] <onrea> lazyPower: ^
[14:05] <onrea> paste.ubuntu.com/7054706/
[14:05] <onrea> should I install nginx, too?
[14:06] <lazyPower> hmm no
[14:06] <lazyPower> hang on
[14:06] <lazyPower> i'm downgrading juju
[14:07] <lazyPower> you're getting a cloudinit-img failure on container creation, i dont know that i have the solution but i'll try to reproduce it
[14:08] <onrea> lazyPower: Is it a thing related to #lxcontainers irc channel?
[14:08] <lazyPower> not really
[14:08] <lazyPower> it has to do with how juju is bootstrapping the lxc containers
[14:09] <lazyPower> if i understand the problem correctly
[14:09] <onrea> If this help, here is my try on wordpress: http://askubuntu.com/q/431313/152405
[14:12] <lazyPower> onrea: lets try something. lets destroy your current environment and upgrade you to the devel release of juju
[14:12] <marcoceppi> onrea: what version of Ubuntu are you using?
[14:13] <marcoceppi> nvm, saucy
[14:13] <marcoceppi> duh
[14:13] <onrea> marcoceppi: 13.10 sausy, full updated
[14:14] <onrea> lazyPower: Ok, I destroy it.
[14:15] <marcoceppi> It looks like you don't have the cloudimg downloaded, onrea can you paste the results of `sudo ls -ah /var/cache/lxc/cloud-precise/`
[14:15] <onrea> Does it have any special PPA? I mean devel release
[14:15] <lazyPower> onrea: ppa:juju/devel
[14:15] <onrea> w8
[14:16] <onrea> marcoceppi:
[14:16] <onrea> ls: cannot access /var/cache/lxc/cloud-precise: No such file or directory
[14:16] <marcoceppi> onrea: yeah, you don't hvae the cloud image, that's why you're getting that error
[14:16] <marcoceppi> it should be installed on first bootstrap
[14:16] <marcoceppi> onrea: do you have juju-local package installed?
[14:17] <onrea> but I does not get any error on bootstraping
[14:17] <marcoceppi> onrea: well, the bootstrap isn't an LXC machine, it's your host machine
[14:17] <onrea> juju-local ---> installed
[14:18] <marcoceppi> onrea: try bootstrapping one more time, then try to deploy a service after it bootstraps
[14:18] <marcoceppi> if you get the same error let us know
[14:18] <onrea> ok, w8
[14:19] <onrea> I send the commands step by step when I run them.
[14:20] <onrea> sudo apt-get install juju juju-local charm-tools
[14:20] <onrea> Done.
[14:20] <onrea> juju init && juju switch local
[14:20] <onrea> Done
[14:21] <onrea> sudo juju bootstrap
[14:21] <onrea> Done
[14:22] <onrea> juju deploy wordpress
[14:22] <onrea> Done
[14:22] <onrea> juju deploy mysql
[14:23] <onrea> Done
[14:23] <onrea> juju add-relation wordpress mysql
[14:23] <onrea> Done
[14:23] <onrea> juju expose wordpress
[14:23] <onrea> Done
[14:24] <marcoceppi> onrea: what does juju status show now?
[14:25] <onrea> => http://paste.ubuntu.com/7056018/
[14:25] <onrea> marcoceppi: ^
[14:25] <lazyPower> thats so strange that its not fetching the cloud image
[14:26] <marcoceppi> onrea: what's `sudo ls -lah /var/cache/lxc/` show? Also do you have any restrictions on your networking?
[14:26] <onrea> w8
[14:26] <onrea> 3 lines in output:
[14:26] <onrea> total 8.0K
[14:27] <onrea> drwx------  2 root root 4.0K Jan 16 19:56 .
[14:27] <onrea> drwxr-xr-x 22 root root 4.0K Mar  8 16:47 ..
[14:28] <onrea> Restrictions on up/down: nope. let me try it behind VPN.
[14:29] <onrea> when I run `juju init && juju switch local`, it says:
[14:29] <onrea> A boilerplate environment configuration file has been written to /home/emzi/.juju/environments.yaml. Edit the file to configure your juju environment and run bootstrap. Changed default environment from "amazon" to "local"
[14:30] <onrea> doesn't it need an configuration?
[14:30] <onrea> any*
[14:31] <onrea> lazyPower: which step it tries to fetch "cloud image"?
[14:34] <lazyPower> onrea: not for the local provider
[14:34] <lazyPower> it should "just work"
[14:35] <lazyPower> Do you have any kind of filtering on your network? is there any thing that could possibly prevent you from downloading that image such as a complex routing scheme, multiple networks attached, tor, etc.
[14:37] <onrea> hmm, here is Iran. Are'n you banning our IPs?
[14:41] <onrea_> alo?
[14:41] <onrea_> where can I find the name of packages?
[14:42] <onrea_> Maybe they includes something as in sex, etc which not accepted by iran censorship!
[14:45] <lazyPower> Well, i doubt its anything like that, but its a possibility its being filtered out
[14:46] <lazyPower> if you have a VPN in another country, i would recommend trying that.
[14:51] <onrea_> lazyPower: I hav a VPN that does not support ssh, Is it ok?
[14:51] <lazyPower> should be, it wget's the cloud image
[15:03] <onrea_> I found this post: https://www.stgraber.org/2013/12/21/lxc-1-0-your-second-container/ , Isn't useful. (because: there is this kind of error in the `juju status` output: md64 -a amd64 ''!='' i386)
[15:10] <lazyPower> onrea_: can you reach cdimages.ubuntu.com?
[15:15] <onrea_> lazyPower: sure, it opens here
[15:15] <onrea_> may you look at this: https://bbs.archlinux.org/viewtopic.php?pid=1312627#p1312627
[15:16] <lazyPower> yep, juju is doing something like that
[15:17] <lazyPower> if you can reach cdimages, can you reach cloud-images.ubuntu.com as well?
[15:17] <onrea_> I do this: sudo aptitude install cloud-utils
[15:17] <onrea_> It wan not installed!
[15:23] <onrea_> lazyPower: juju status -> http://paste.ubuntu.com/7056316/ -> The error went :) -> But why "agent-state" is pending?
[15:27] <lazyPower> there have been some fixes to LXC based deployments in the dev branch
[15:27] <lazyPower> which is why i initially suggested you run the devel branch while testing
[16:09] <onrea> lazyPower: Now, I'm on ppa:juju/devel | here is a conflict:
[16:09] <onrea> `sudo juju bootstrap`
[16:09] <onrea> ERROR bootstrapping a local environment must not be done as root
[16:10] <onrea> `juju bootstrap`
[16:10] <onrea> ERROR cannot read environment info for "local": open /home/onrea/.juju/environments/local.jenv: permission denied
[16:11] <marcoceppi> onrea: that's because of <IP_ADDRESS> needing sudo
[16:11] <onrea> It needs `sudo` while it does not need `sudo`.
[16:11] <marcoceppi> onrea: run `sudo chown -R onrea.onrea ~/.juju ~/.ssh`
[16:11] <marcoceppi> then run juju bootstrap
[16:15] <onrea> why chown on ~/.ssh ?
[16:16] <onrea> for installing Discourse, Which one is correct:
[16:16] <onrea> 1. juju add-relation discourse postgresql:db-admin
[16:17] <onrea> 2. juju add-relation discourse:db postgresql:db
[16:17] <onrea> 1/2?
[16:19] <onrea> Oops; instance-id: pending ;  why?
[16:19] <onrea> postgresql/0:         agent-state: pending
[16:39] <onrea> Installing Wordpress by JuJu ==> New Error ==> http://paste.ubuntu.com/7056689/
[16:39] <onrea> ==> error: container "onrea-local-machine-1" is already created
[16:39] <onrea> Also ==> agent-state: pending
[16:44] <avoine> onrea: destroy your environnement and checkout that your machine are gonne in /var/lib/lxc/
[16:44] <avoine> if not use lxc-stop -n
[16:44] <avoine> and lxc-destroy
[16:45] <avoine> also don't forget to clean /etc/lxc/autostart/
[16:50] <onrea> ok
[16:51] <onrea> avoine: sudo juju destroy-environment => does not work sinc I migrated to `devel` repo. it says: error: no environment specified
[16:53] <avoine> onrea: try   sudo juju -e local destroy-environment
[16:53] <onrea> avoine: ls /var/lib/lxc/
[16:54] <onrea> onrea-local-machine-1  onrea-local-machine-2  onrea-local-machine-1  onrea-local-machine-2
[16:54] <avoine> that's it
[16:54] <avoine> juju had a bug where it did not cleanup local machine proprelly
[16:55] <onrea> avoine: sudo juju -e local destroy-environment => error: flag provided but not defined: -e
[16:55] <avoine> oups
[16:55] <lazyPower> onrea: youdont need the -e flag
[16:55] <lazyPower> its positional arguements in 1.17.x
[16:55] <lazyPower> sorry i'm gearing up for a presentation
[16:56] <lazyPower> onrea: I should have specified that you need to destroy your environment in the 1.16.x series before the upgrade
[16:56]  * avoine needs to reboot
[16:56] <onrea> agent-version: <IP_ADDRESS>
[16:56] <lazyPower> onrea: what you'll need to do is clean up the LXC containers from your system that are left behind. there's an ask ubuntu post on this let me go find it
[16:56] <lazyPower> onrea: http://askubuntu.com/questions/403618/how-do-i-clean-up-a-machine-after-using-the-local-provider/403619#403619
[16:57] <lazyPower> follow those instructions to clear out your juju local deployment from the 1.16.x series. Then, once you've completed that and verify you have no leftovers, rebootstrap the environment and your lxc woes should go away
[16:57] <onrea> ok, w8
[16:58] <lazyPower> onrea: i'll be in and out for the next half hour. Showering and getting ready to head out for this meeting. I'll stop in and check on you before i leave.
[17:01] <onrea> lazyPower: Ok, I'll open a topic in discourse.ubuntu.com mentionanig you this way @lazyPower
[17:02] <onrea> then, should I restart?
[17:03] <onrea> This 2 command didn't work: sudo rm -r /etc/lxc/auto/juju-* AND sudo rm -r /var/lib/lxc/juju-*
[17:25] <zchander> Can anyone point me the correct direction for a reverse proxy setup (on a MAAS region/cluster controller combi), so I can reach deployed charms in the cluster?
[17:31] <lazyPower> zchander: you may want to ask that again on Monday. Most of the people are offline for their weekend.
[17:31] <lazyPower> or email the list, and someone should get back to you
[17:36] <zchander> I'll try monday again..., thanks
[17:37] <lazyPower> zchander: sorry i wasn't more help. I dont want to abandon you since I saw you ask around Friday late afternoon
[17:37] <lazyPower> if you dont have an answer monday let me know and i'll try to run someone down for you. We are pretty busy with the 14.04 release coming up
[17:38] <zchander> No problem at all...   ERROR ==> http://paste.ubuntu.com/7057154/ ==> I've just downlowded https://cloud-images.ubuntu.com/server/releases/precise/release-20140227/ubuntu-12.04-server-cloudimg-amd64.tar.gz ==> How to install it
[18:21] <onrea> purged*
[18:22] <onrea> Is it possible to install ubuntu-12.04-server-cloudimg-amd64.tar.gz manually?
[18:26] <onrea> ubuntu-12.04-server-cloudimg-amd64.tar.gz
[18:26] <onrea> ubuntu-12.04-server-cloudimg-amd64-root.tar.gz
[18:39] <zchander> Saw it may be too late, but: Break a leg, lazyPower!
[19:49] <onrea> ==> http://askubuntu.com/q/431441/152405


[08:11] -queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/4690 Proposed pocket (jammy/compiz). Ready to build (/:, /: Failed to update local lp:compiz cache., jammy/Failed, jammy/cache., jammy/local, jammy/lp:compiz, jammy/to, jammy/update)
[08:13] -queuebot:#ubuntu-ci-eng- 3v1n0, https://bileto.ubuntu.com/#/ticket/4692 Proposed pocket (impish/unity). Ready to build (/: Failed to update local lp:unity cache.)
[08:14] -queuebot:#ubuntu-ci-eng- 3v1n0, https://bileto.ubuntu.com/#/ticket/4693 Proposed pocket (focal/unity). Ready to build (/: Failed to update local lp:unity cache.)
[08:14] -queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2393 Failed to build (xenial/aethercast). Needs rebuild due to higher version at destination (zesty/aethercast). Ready to build (/:, /: Failed to update local lp:aethercast cache., xenial/Failed, xenial/cache., xenial/local, xenial/lp:aethercast, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:aethercast, zesty/to, zesty/update)
[08:18] -queuebot:#ubuntu-ci-eng- andyrock, https://bileto.ubuntu.com/#/ticket/3658 Failed to build (disco/nux). Ready to build (/:, /: Failed to update local lp:nux cache., disco/Failed, disco/cache., disco/local, disco/lp:nux, disco/to, disco/update)
[08:23] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4442 Ready to build (/:, /: Failed to update local lp:bamf cache., focal/Failed, focal/cache., focal/local, focal/lp:bamf, focal/to, focal/update). Successfully built (focal/bamf)
[08:23] -queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2162 Needs rebuild due to higher version at destination (zesty/aethercast). Ready to build (/:, /: Failed to update local lp:aethercast cache., xenial/Failed, xenial/cache., xenial/isc-dhcp, xenial/local, xenial/lp:aethercast, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/isc-dhcp, zesty/local, zesty/lp:aethercast, zesty/to, zesty/update). Successfully built (xenial/aethercast)
[08:33] -queuebot:#ubuntu-ci-eng- 3v1n0, https://bileto.ubuntu.com/#/ticket/4692 Proposed pocket (impish/unity). Ready to build (/:, /: Failed to update local lp:unity cache., impish/Failed, impish/cache., impish/local, impish/lp:unity, impish/to, impish/update)
[08:34] -queuebot:#ubuntu-ci-eng- 3v1n0, https://bileto.ubuntu.com/#/ticket/4693 Proposed pocket (focal/unity). Ready to build (/:, /: Failed to update local lp:unity cache., focal/Failed, focal/cache., focal/local, focal/lp:unity, focal/to, focal/update)
[09:06] -queuebot:#ubuntu-ci-eng- paelzer, https://bileto.ubuntu.com/#/ticket/4705 Successfully built
[09:19] -queuebot:#ubuntu-ci-eng- andyrock, https://bileto.ubuntu.com/#/ticket/3658 Failed to build (disco/nux). Ready to build (/:, disco/Failed, disco/cache., disco/local, disco/lp:nux, disco/to, disco/update)
[09:23] -queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2162 Needs rebuild due to new commits (zesty/aethercast). Ready to build (/:, xenial/Failed, xenial/cache., xenial/isc-dhcp, xenial/local, xenial/lp:aethercast, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/isc-dhcp, zesty/local, zesty/lp:aethercast, zesty/to, zesty/update). Successfully built (xenial/aethercast)
[09:23] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4442 Ready to build (/:, focal/Failed, focal/cache., focal/local, focal/lp:bamf, focal/to, focal/update). Successfully built (focal/bamf)
[09:30] -queuebot:#ubuntu-ci-eng- paelzer, https://bileto.ubuntu.com/#/ticket/4709 Currently building (jammy/postgresql-14). Diff missing (jammy/openssl). Failed to build (jammy/postgresql-13)
[09:31] -queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/4690 Proposed pocket (jammy/compiz). Ready to build (/:, jammy/Failed, jammy/cache., jammy/local, jammy/lp:compiz, jammy/to, jammy/update)
[09:33] -queuebot:#ubuntu-ci-eng- 3v1n0, https://bileto.ubuntu.com/#/ticket/4692 Proposed pocket (impish/unity). Ready to build (/:, impish/Failed, impish/cache., impish/local, impish/lp:unity, impish/to, impish/update)
[09:34] -queuebot:#ubuntu-ci-eng- 3v1n0, https://bileto.ubuntu.com/#/ticket/4693 Proposed pocket (focal/unity). Ready to build (/:, focal/Failed, focal/cache., focal/local, focal/lp:unity, focal/to, focal/update)
[09:35] -queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2393 Failed to build (xenial/aethercast). Needs rebuild due to new commits (zesty/aethercast). Ready to build (/:, xenial/Failed, xenial/cache., xenial/local, xenial/lp:aethercast, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:aethercast, zesty/to, zesty/update)
[11:24] -queuebot:#ubuntu-ci-eng- paelzer, https://bileto.ubuntu.com/#/ticket/4703 Pending binary packages
[11:44] -queuebot:#ubuntu-ci-eng- paelzer, https://bileto.ubuntu.com/#/ticket/4703 Successfully built
[12:24] -queuebot:#ubuntu-ci-eng- slyon, https://bileto.ubuntu.com/#/ticket/4704 Failed to build
[12:50] -queuebot:#ubuntu-ci-eng- paelzer, https://bileto.ubuntu.com/#/ticket/4709 Diff missing (jammy/openssl). Pending binary packages (jammy/postgresql-13, jammy/postgresql-14)
[13:10] -queuebot:#ubuntu-ci-eng- paelzer, https://bileto.ubuntu.com/#/ticket/4709 Diff missing
[13:54] -queuebot:#ubuntu-ci-eng- 3v1n0, https://bileto.ubuntu.com/#/ticket/4693 Ready to build (/:, focal/Failed, focal/cache., focal/local, focal/lp:unity, focal/to, focal/update). Updates pocket (focal/unity)
[15:04] -queuebot:#ubuntu-ci-eng- slyon, https://bileto.ubuntu.com/#/ticket/4704 Uploading build
[15:24] -queuebot:#ubuntu-ci-eng- slyon, https://bileto.ubuntu.com/#/ticket/4704 Pending binary packages
[15:44] -queuebot:#ubuntu-ci-eng- slyon, https://bileto.ubuntu.com/#/ticket/4704 Diff missing
[15:45] -queuebot:#ubuntu-ci-eng- slyon, https://bileto.ubuntu.com/#/ticket/4704 Generating diffs
[15:46] -queuebot:#ubuntu-ci-eng- slyon, https://bileto.ubuntu.com/#/ticket/4704 Successfully built
[18:04] -queuebot:#ubuntu-ci-eng- paelzer, https://bileto.ubuntu.com/#/ticket/4703 Pending binary packages
[18:24] -queuebot:#ubuntu-ci-eng- paelzer, https://bileto.ubuntu.com/#/ticket/4703 Successfully built


[00:17] <zotta> I want to execute a conversion program on data uploaded to a website. However the converter is known to have security issues all the time.
[00:17] <zotta> Is there a way to run such a program in a sandbox?
[00:17] <zotta> Basically I want to restrict reading files to one input file and writing to one output file, prevent network access and limit execution time and ram
[00:21] <sarnold> zotta: you can wrap the converter in an apparmor profile
[00:21] <Patrickdk> well, if you combine apparmor and ulimit will do most of that
[00:21] <Patrickdk> but never looked at limiting network access
[00:22] <sarnold> apparmor can deny network access, "deny network," ought to do the trick -- but that might also forbid e.g. unix sockets if that's how the web server drives it, hehe
[00:23] <jjohansen> sarnold: sure but you can allow unix sockets, and just not allow network
[00:24] <jjohansen> since its default deny, network will be denied
[00:24] <sarnold> hey jjohansen :)
[00:24] <jjohansen> hey sarnold
[00:26] <zotta> Does it support whitelist for file read access?
[00:26] <sarnold> zotta: yes
[00:26] <sarnold> zotta: for example, here's my irssi (irc client) profile: http://paste.ubuntu.com/10062642/
[00:27] <zotta> Sounds great. I will up on it.
[00:27] <sarnold> hmm, that could use some slight improvements...
[00:27] <sarnold> but I hope it helps convey the flavour of apparmor profiles :)
[00:28] <zotta> :) thx
[02:00] <Patrickdk> I had to adjust my apparmour profile today :(
[02:00] <Patrickdk> users couldn't send email
[02:01] <jjohansen> Patrickdk: what was the message that was logged?
[02:01] <jjohansen>   dmesg | grep DENIED
[02:01] <jjohansen> or
[02:01] <jjohansen>   grep DENIED /var/log/syslog
[02:01] <Patrickdk> heh?
[02:02] <Patrickdk> the message that was logged was, denied x to /usr/sbin/sendmail
[02:03] <Patrickdk> as, by normal sanity, there is nothing in /usr/sbin a user needs, except sendmail aparently
[02:04] <sarnold> you let your users send email? how decadent :)
[02:05] <Patrickdk> sarnold, heh, it's been like this for years, first time someone had a problem
[02:05] <sarnold> :)
[02:05] <Patrickdk> calling sendmail is such a hack though
[02:05] <jjohansen> Patrickdk: so since we don't supply a send mail profile I would recommend going with either
[02:05] <jjohansen>   /usr/bin/sendmail  ix,
[02:05] <jjohansen> or
[02:05] <jjohansen>   /usr/bin/sendmail pix,
[02:06] <Patrickdk> wouldn't work
[02:06] <Patrickdk> /usr/sbin/sendmail ix
[02:06] <Patrickdk> is what I used
[02:06] <Patrickdk> it then required, /usr/sbin/postdrop ix
[02:06] <jjohansen> oh fun
[02:08] <Patrickdk> name="/usr/sbin/sendmail" pid=10663 comm="mailx" requested_mask="x" denied_mask="x"
[02:09] <Patrickdk> I just have a huge profile I wrote, that gives the users exactly what they need and nothing else
[02:10] <Patrickdk> then I locked it to bash and dash
[02:10] <Patrickdk> works really well
[02:10] <jjohansen> nice
[02:10] <Patrickdk> users start with bash shell, and can't change it
[02:11] <Patrickdk> hmm, only 133 lines :)
[02:12] <Patrickdk> I saw apache suexec got apparmor support :) that is nice
[02:12] <Patrickdk> I had patched mine a long time ago with it, works well there too
[02:14] <jjohansen> oh nice, I didn't know that suexec had apparmor support, /me will have to look at what they are doing. apparmor does have the mod_apparmor apache plugin that allows profiles to be set based off of urls etc
[02:15] <jjohansen> but the suexec change is new to me
[02:15] <Patrickdk> oh, maybe it was mod_apparmor
[02:15] <Patrickdk> I know it could use hatchange in apache
[02:15] <Patrickdk> and suexec would be affected
[02:15] <Patrickdk> maybe it wasn't directly in suexec
[02:17] <jjohansen> ah maybe still worth looking into
[04:12] <grendal_prime> you know this seems stupid..like i should know this, but isnt it possible to send all traffic destined for an fqdn to a local ip.... i mean without setting the hosts file on the client?
[04:13] <grendal_prime> i have a dns server but i only want to do this with...like port 80 traffic
[04:55] <grendal_prime> ya so this is whack
[05:08] <grendal_prime> it seems like if i set that in the hosts file of my ubuntu router, it should just route things to there.
[05:08] <grendal_prime> but that is not working
[06:24] <lordievader> Good mornining
[06:24] <sarnold> grendal_prime: hunt around for a "transparent proxy howto", it'll have iptables rules that you can use to redirect traffic as you wish
[06:25] <grendal_prime> ya thats how i usually do this..but that does not seem to be working
[06:25] <grendal_prime> i cant figure out what the heck is going on actually
[06:27] <grendal_prime> i have used haproxy to do this as well..but its werid..its like my ip tables changes are not taking effect.
[07:00] <grendal_prime> sarnold, i actually like the haproxy approach for what im doing, cause i can subdomain the web requests...and well also the xmpp i think.
[07:00] <grendal_prime> well...maybe not on those.
[07:01] <grendal_prime> well actually it looks like ya thats doable
[07:03] <grendal_prime> the proxy works from outside..but..hmm i think this is an issue with the router/firewall between my router/firewall and the wall.
[07:03] <grendal_prime> this is getting very frustrating.  The domain does not resolve to that internal ip and, hmm
[07:41] <grendal_prime> this is fn crazy
[07:41] <grendal_prime> i just...grrrrrr
[07:42] <grendal_prime> I have access to the dhcp server..i have access to the dns server...i cant make the internal machines go to something inside instead of outside the network?
[07:42] <grendal_prime> its just nuts
[13:09] <Anteac> im got aids
[13:09] <Anteac> just now
[13:09] <Anteac> from serverpilot
[13:24] <alias_neo> Hi guys, I'm trying to get the hw_random working in my xeon on ubuntu server, I'm struggling to get it to work properly, anybody got experience with it? I cant seem to get the intel kernel module to load and /dev/hwrng doesn't show up unless i start virtio-rng
[13:32] <alias_neo> Is 19GiB/s plausible for urandom if it's not using hwrng?
[13:33] <alias_neo> rngtest: input channel speed: (min=2.161; avg=169.892; max=19073.486)Mibits/s
[13:33] <alias_neo> or is that a red herring?
[14:00] <patdk-wk> hwrng has nothing to do with urandom
[14:01] <patdk-wk> urandom is based purely on your cpu bandwidth
[14:06] <jrwren> alias_neo: remember: http://www.2uo.de/myths-about-urandom/
[14:08] <alias_neo> jrwren thanks
[14:10] <jrwren> alias_neo: afaik, kernel will use RDRAND if the instruction is available.
[14:12] <alias_neo> my rngtest bandwidth doesn't seeem to suggest I'm using the hwrand capability of my Xeon
[14:12] <alias_neo> rngd doesn't see it, modprobe-ing intel-rng doesn't work (no such device)
[14:15] <alias_neo> I'd like to be able to pass the hardware rng through to my kvm guests, because my IPA server for example on F21 is running out of entropy all the time
[14:18] <alias_neo> crap, now my ubuntu server has dropped my ssh connection and won't reconnect
[16:13] <jsmith-argotec> hi all
[16:15] <jsmith-argotec> how would I figure out the exact versions of each library dependency that would be installed with a package from the 12.04.00 without installing 12..04 from original media and installing the package?
[16:18] <pmatulis> jsmith-argotec: is this what you're looking for?  http://paste.ubuntu.com/10075458/
[16:18] <pmatulis> jsmith-argotec: ah, without installing 12.04
[16:20] <pmatulis> jsmith-argotec: probably a few ways but i think the easiest is to create an LXC container and doing the above
[16:24] <jsmith-argotec> pmatulis: hmm ok ty
[16:25] <jsmith-argotec> I'm having a problem with my pacemaker cluster software after the server was rebooted.  One direction I'm going down is that a security update to a library may have caused an incompatiblity with the package
[16:25] <jsmith-argotec> different question - what should I look for in an strace to help look in the right direction?
[16:26] <pmatulis> jsmith-argotec: it would depend on the problem.  w/o specifics it's hard to help
[16:27] <jsmith-argotec> ok I'm getting "corosync [IPC ] Invalid IPC credentials" error when I start pacemaker followed by "attrd: [28829]: ERROR: main: HA Signon failed"
[16:28] <jsmith-argotec> pmatulis: corosync communications are working and both nodes are members.  When I start pacemaker I get those ^^^ errors
[16:29] <ivoks> jsmith-argotec: er
[16:29] <jsmith-argotec> pmatulis: what started it was the node was fenced. after reboot it wouldn't rejoin and had these errors.  I found it had booted with an incorrect kernel which I correct but still getting the same errors
[16:29] <jsmith-argotec> ivoks: hi!
[16:29] <ivoks> jsmith-argotec: check package version of pacemaker and liblrmd
[16:30] <jsmith-argotec> ivoks: I was wondering if its the same issue that was just SRU'd in trusty and up
[16:30] <jsmith-argotec> ivoks: ... no liblrmd installed...
[16:30] <ivoks> liblrmd1
[16:30] <ivoks> or something
[16:30] <ivoks> dpkg -l | grep liblrmd
[16:30] <ivoks> dpkg -l | grep pacemaker
[16:30] <jsmith-argotec> got it
[16:30] <sarthor> Hi, I have ubuntu-server 14.04 running, when ubuntu export some text to pdf, I can not see arabic words in a proper way. irregular fonts showing, How can I fix this. HELLP please.
[16:31] <ivoks> version should be exactly the same
[16:31] <jsmith-argotec> not even close
[16:31] <jsmith-argotec> 1.1.6-2ubuntu3 for pacemaker, 1.0.8-2ubuntu6 for liblrm2
[16:31] <ivoks> uh, that's an old version
[16:31] <jsmith-argotec> on 12.04
[16:31] <jsmith-argotec> precise
[16:31] <ivoks> liblrmd
[16:31] <ivoks> not liblrm
[16:32] <jsmith-argotec> dpkg -l | grep liblr
[16:32] <jsmith-argotec> ii  liblrm2                              1.0.8-2ubuntu6                    Reusable cluster libraries -- liblrm2
[16:32] <jsmith-argotec> that's all I have
[16:32] <ivoks> i don't remember how it was in 12.04
[16:33] <sarthor> sarthor:
[16:33] <jsmith-argotec> ivoks: not available for install via apt-get either
[16:33] <pmatulis> 1.0.8-2ubuntu6 is correct on 12.04
[16:34] <jsmith-argotec> according to showpkg dependecies lists liblrm2 not liblrmd
[16:34] <pmatulis> but pacemaker is 1.1.6-2ubuntu3.3
[16:34] <ivoks> that's fine
[16:34] <ivoks> liblrm is not from pacemaker source
[16:34] <ivoks> it's from cluster-glue
[16:35] <jsmith-argotec> pmatulis: yes thats the latest but I was running 1.1.6-2ubuntu3 when I had issues. tried upgrading which didn't help
[16:35] <pmatulis> oh
[16:35] <ivoks> did you just upgrade pacemaker or did you do dist-upgrade?
[16:35] <jsmith-argotec> and downgraded back just in cast
[16:35] <jsmith-argotec> case
[16:35] <jsmith-argotec> just pacemaker
[16:36] <pmatulis> so problems with both versions?
[16:36] <jsmith-argotec> but I have upgrade some libraries along the way from security etc
[16:36] <jsmith-argotec> pmatulis: yes
[16:36] <ivoks> see if dist-upgrade will install something in addition
[16:37] <jsmith-argotec> and I put other working node in maintenance and restarted the services there and now it's exhibiting the same errors
[16:37] <pmatulis> jsmith-argotec: did you ever reboot successfully on any version?
[16:37] <jsmith-argotec> pmatulis: yes I have a reboot/successful rejoin from Decemeber
[16:38] <pmatulis> jsmith-argotec: and you rebooted again, w/o changing anything and you have problems?
[16:38] <pmatulis> jsmith-argotec: and then you tried fixing by upgrading stuff?
[16:38] <jsmith-argotec> ivoks: theres over 300 packages that would update... dont really want to update all of them
[16:39] <ivoks> try upgrading cluster-glue, if available
[16:39] <jsmith-argotec> pmatulis: node was fenced so it rebooted, then it didn't work.  There had been (at least) one package installed between.
[16:39] <jsmith-argotec> pmatulis: it booted with a newer kernel also which I reverted and also uninstalled everything from the last package install.  Still not working so I tried the upgrade
[16:40] <jsmith-argotec> ivoks: nothing new for cluster-glue
[16:40] <ivoks> i doubt that
[16:40] <ivoks> i bet on user error :)
[16:41] <jsmith-argotec> doubt what... nothing new for cluster-glue/
[16:41] <jsmith-argotec> ?
[16:41] <ivoks> are you starting pacemaker as a service or is corosync starting it?
[16:42] <jsmith-argotec> I start corosync manually and then pacemaker manually (plugin ver 1)
[16:42] <jsmith-argotec> as a service
[16:43] <jsmith-argotec> for history these 2 nodes have been running stable in production (failed over a few times as designed) for over 18 months
[16:43] <ivoks> mount | grep shm
[16:43] <jsmith-argotec> ivoks: it's on tmpfs:  none on /run/shm type tmpfs (rw,nosuid,nodev)
[16:43] <jsmith-argotec> which is correct I believe?
[16:44] <ivoks> yes
[16:44] <ivoks> and /var/run/crm exists?
[16:44] <jsmith-argotec> in the strace there was something about libgpg-error right around the time of the HA signon error in the logs... is that something?
[16:44] <sarthor> Hi, I have ubuntu-server 14.04 running, when ubuntu export some text to pdf, I can not see arabic words in a proper way. irregular fonts showing, How can I fix this. HELLP please.
[16:45] <ivoks> is /var/run also tmpfs?
[16:46] <jsmith-argotec>  run is... tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
[16:46] <jsmith-argotec> none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
[16:46] <jsmith-argotec> none on /run/shm type tmpfs (rw,nosuid,nodev)
[16:46] <ivoks>  /var/run
[16:46] <jsmith-argotec> don't see /var/run
[16:46] <jsmith-argotec>  /var/run -> /run
[16:46] <ivoks> do you have /var/run/crm?
[16:46] <jsmith-argotec> and run is on tmpfs
[16:47] <jsmith-argotec> yes
[16:47] <jsutherland> Our next server is likely going to be a Dell R730 or HP DL380 Gen9. Both run best with either Dell or HP branded SAS drives. What limitations would I run into if I use generic Seagate SAS drives?
[16:48] <ivoks> jsmith-argotec: and permissons on stuff in /var/run/crm look ok?
[16:48] <jsmith-argotec> umm no.. hang on
[16:48] <jsmith-argotec> all should be hacluster:haclient right?
[16:49] <ivoks> do you have another cluster running on the same network?
[16:49] <jsmith-argotec> no
[16:49] <jsmith-argotec> uhh wait
[16:49] <jsmith-argotec> maybe
[16:49] <ivoks> quite possible, i'd say
[16:49] <ivoks> and you didn't set authkey
[16:50] <ivoks> or change the multicast port
[16:50] <jsmith-argotec> let me check that!
[16:56] <jsmith-argotec> ivoks: yes there are two 2 node clusters... wasn't thinking about the other set the other admin setup.
[16:57] <ivoks> always use authkey in corosync
[16:57] <jsmith-argotec> but.. both have secauth on, authkey created, both have 2 rings on 2 seperate redundant nics (2 direct connect, 2 LAN), and all 4 are different mcast addresses
[16:57] <ivoks> always.
[16:57] <ivoks> you need to change mcast port
[16:58] <jsmith-argotec> so each cluster needs to use a different port at least on the common LAN even if different mcast addresses?
[16:59] <ivoks> which mcast addresses do you use?
[16:59] <jsmith-argotec> isn't that particular to corosync communications not pacemaker or am I way off?  'cause both nodes are members of the coro rings
[16:59] <ivoks> both?
[16:59] <ivoks> you have only two nodes?
[17:00] <jsmith-argotec> one cluster: mcastaddr: <IP_ADDRESS>, mcastaddr: <IP_ADDRESS>.  second cluster: <IP_ADDRESS>,  <IP_ADDRESS>, all port 5405
[17:00] <jsmith-argotec> yes only 2 nodes in each cluster, 2 clusters
[17:01] <ivoks> er
[17:01] <ivoks> different mcast addresses on different nodes in the same cluster?
[17:01] <jsmith-argotec> I can pastebin the corosync.conf if you like?
[17:01] <ivoks> sure
[17:02] <ivoks> oh, those are different rings
[17:03]  * ivoks is around for next few minutes, and then I'm out of here
[17:03] <jsmith-argotec> http://paste.ubuntu.com/10076093/
[17:05] <ivoks> http://manpages.ubuntu.com/manpages/saucy/man5/votequorum.5.html
[17:05] <jsmith-argotec> this is the config from the 2 nodes that are having the issue
[17:05] <ivoks> SPECIAL FEATURES
[17:05] <ivoks> two_node: 1
[17:08] <jsmith-argotec> ivoks: but it has been working fine for months... or was that just dumb luck?
[17:10] <ivoks> it works while there's no distruption
[17:10] <ivoks> or if you reboot both at the same time
[17:11] <ivoks> if you reboot one by one, all kinds of things can happen
[17:11] <ivoks> i'm not sure that's the cause of your problem, but for start, your configuration is missing this important bit
[17:11] <jsmith-argotec> OK will correct that one
[17:29] <sarthor> Hi, I have ubuntu-server 14.04 running, when ubuntu export some text to pdf, I can not see arabic words in a proper way. irregular fonts showing, How can I fix this. HELLP please.
[17:43] <hallyn> jdstrand: hm.  well, the thing is, the libvirt-qemu file ends in '}', so appending a rule doesn't suffice :)  i wonder why it worked in the karmic case.
[17:44] <hallyn> i guess i'll just sed the file first...
[18:04] <hallyn> wait, that's messed up
[18:06] <hallyn> heh, mea culpa
[18:24] <jdstrand> hallyn: actually, it would suffice cause the '}' corresponds to the 'profile qemu_bridge_helper {' child profile
[18:24] <jdstrand> hallyn: (however, karmic didn't have that child profile)
[18:26] <hallyn> yeah;  so i'm trying ot figure out why it's still not working
[18:26] <jdstrand> hallyn: but if you're adding a rule that is covered by an explicit deny rule, remember that deny rules are evaluated after allow rules, so you may need a sed regardless
[18:26] <hallyn> mayb ei'll just do /tmp/** rw
[18:26] <hallyn> oh,
[18:26] <jdstrand> yeah
[18:26] <hallyn> i thought 'deny rules evaluated after allow rules' meant they are subservient
[18:26] <jdstrand> deny /tmp/** r,
[18:27] <jdstrand> /tmp/** r,
[18:27] <jdstrand> the deny always wins that
[18:27] <hallyn> near as i can tell i can't use testlib then
[18:27] <hallyn> or, i'll just make a backup and then sed to my heart's content, i guess
[18:27] <jdstrand> hallyn: you can-- just not with append
[18:27] <jdstrand> hallyn: read in the contents, remove the deny rules, add your rule, then replace the file without appending
[18:28] <hallyn> that seems more complicated
[18:28] <jdstrand> testlib should support what I just mentioned
[18:28]  * hallyn looks
[18:28] <jdstrand> it is, but it means you can simply use a _restore() in the tearDown
[18:29] <hallyn> i can still do that if i make the backup using testlib._bakcup
[18:30] <jdstrand> hallyn: _update_config in test-libvirt.py does basically what I said
[18:30] <jdstrand> hallyn: it could be much simpler for your case, but it is there for inspiration
[18:31] <hallyn> jdstrand: ok, thanks
[18:31] <jdstrand> np
[18:31] <hallyn> i'd thought this would be a quick fix, but i'm messing it up at each attempt :)  there's still another but to fix before we can release, sigh
[20:36] <jsmith-argotec> ivoks: I made the quorum change and both members rejoined.  Still getting the same error though
[22:41] <dtscode> hey guys... i followed this https://www.digitalocean.com/community/tutorials/how-to-set-up-apache-virtual-hosts-on-ubuntu-12-04-lts but when i get to sudo a2ensite ts3.dtscode.io it says ERROR: Site ts3.dtscode.io does not exist! how can i fix this?
[22:52] <justizin> is it just me, or does trusty not have add-apt-repository? *looks confused*
[22:53] <justizin> i mean, i guess i can add it manually, it just seems like a lot of trouble has been gone to to make this simple..
[22:53] <justizin> apt-cache search add-apt-repository also comes up empty for me
[22:55] <sarnold> dtscode: did you name your config file with a .conf file extension? I think that's required
[22:56] <sarnold> justizin: it's in the software-properties-common package
[22:56] <dtscode> sarnold, thanks :D that did it
[22:56] <justizin> interesting.. i guess i have typically gotten that by installing python-software-properties, but it now installs python3-software-properties
[22:56] <justizin> i'll try to remember software-properties-common :)
[22:57] <justizin> also i guess the official ubuntu vagrant virtualbox image doesn't have it, not sure if it's expected to be present.
[22:57] <justizin> kind of seems like it makes sense to be, but i'm sure there was some long arcane e-mail flamewar that resulted in this decision. ;d
[22:57] <sarnold> I suspect the truth is less interesting than you suspect :) hehe
[22:59] <justizin> sarnold: likely. :)
[23:10] <justizin> btw tks sarnold!
[23:11] <sarnold> you're welcome justizin :)
[23:35] <arcsky> hello i have some ubuntu servers at work. i wonder if there are any good mangment tool for upgrade and maintain all the servers
[23:40] <sarnold> arcsky: many; landscape, ansible, puppet, chef, cfengine (ancient)


[00:08] <munz> mhall119: (or anyone) can i hide a list of directoried (15-20) from windoes in a samba share on 12.04?
[00:37] <mhall119> munz: does samba automatically hide dotflies?
[00:37] <mhall119> dotfiles
[03:39] <munz> mhall119: i think i got it figured out, ill let you know, thank you


[06:45] <dholbach> good morning
[16:07] <elacheche> Hey!!! Is there a way to track the loco pack?
[18:05] <YoBoY> elacheche, in my case, I received an email from TNT 3 days ago to track the loco pack.
[18:05] <YoBoY> hi