[00:18] so, stupid question but where are the autopkgtests stored [00:18] Hello. I'm having some issues using MariaDB on Ubuntu 16.04. I install it with "apt-get install mariadb-server mariadb-client". When I run "mysql -uroot", however, I get "Access denied for user 'root'@'localhost'". I then run mysql_safe_installation and set a password for the root user, and I still get the same error over and over again when logging in with "mysql -uroot -p" and typing the correct password. any hint? [00:19] teward: how do you mean? [00:19] nacc: well, trying to ID what's going on with nginx [00:19] teward: the tests themselves are in d/t/control [00:19] there's two regressions in diaspora-installer but that's something on their side not nginx [00:19] ah OK [00:19] nacc: looks like i never had to touch them before :p [00:19] i see some nginx fails today, gotta see what that's about :P [00:22] oh hm, ssl curves [00:22] *checks Zesty* [00:24] nacc: any idea how to check what ECDH curves are supported on Zesty? [00:24] teward: i have no idea what that acronym is :) [00:25] i'll ask OpenSSL then [00:26] teward: try "openssl -v" IIRC [00:27] for curves, openssl ecparam -list_curves [00:28] well I know what I have to do. I have to drop a curve... [00:28] who do i prod to change what is acceptable or not for a given test? [00:28] autopkgtest* on the migration tracking system? [00:29] teward: you update the test [00:29] teward: wait, what do you mean 'acceptable'? all tests have to pass [00:30] nacc: I.E. "always failed" or 'Ignored once" [00:30] teward: that's the release team, i believe [00:30] OK [00:31] i'm going to have to drop a test since we don't support the curve... or mark "always failed"... might be easier to drop that curve from the test. [00:32] teward: always failed is typically not set -- it's something autopkgtest runner recognizes [00:32] mmm [00:32] teward: 'failure ignored' is what gets set [00:32] nacc: That's probably what's going to have to be set to get nginx out of proposed, but for more than just nginx. I need to check with Debian in the interim [00:32] teward: so this is a nginx test? [00:33] because i think they added a curve we don't support that got in from Experimental [00:33] nacc: well... [00:33] nacc: two problems: [00:33] (1) NGINX tests fail with Regression, I think it's because there's a curve added to the tests [00:33] teward: it might be apporpirate to add delta is some test depends ona feature we odn't support [00:33] (2) a *different* autopkgtest errors out [00:33] but *not* because of nginx [00:33] teward: let me look [00:33] nacc: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#nginx [00:34] diaspora-installer is the only other one I am not looking into but those errors look like it's a repository problem *not* related ot nginx [00:34] teward: ack, so you're saying we should skip the ec-x25519 test on ubuntu? [00:34] nacc: i'm saying "probably", but I need to figure out its origin [00:34] first [00:34] teward: that should be done via a delta to the src package that either comments out (i prefer this but it's up to you, i think) or deletes it from d/t/control [00:35] nacc: I want to figure out if it's from Debian Exp. or not first [00:35] teward: ack [00:35] that said I need a Debian image too to test [00:35] teward: i'm looking at the other one [00:35] teward: lxc launch images:debian/sid/amd64 [00:35] if it works in Debian but not Ubuntu, then it's a delta that we can comment out for the test [00:35] nacc: already ahead of you [00:35] teward: and/or check ci.debian.net [00:35] but i'm installing the ubuntu-server image in an lxc container. [00:35] or rather, installing that metapackage [00:36] so i have a 'standard' set of crap lol [00:36] https://ci.debian.net/packages/n/nginx/unstable/amd64/ [00:36] seems rather green [00:36] nacc: yeah but i want to make sure that this test is 'new' [00:36] and if it's not 'new' then poke the Security team for a check on OpenSSL in Ubuntu to see if they dropped the curve or something [00:37] being thorough [00:37] teward: http://autopkgtest.ubuntu.com/packages/nginx/zesty/amd64 fwiw as well [00:38] teward: that test wasn't present in the last upload to z-p, it seems [00:38] teward: it is present in debian [00:38] nacc: the 'last upload' to z-p was a half-merge [00:38] it was HTTP/2 fixes ahead of the actual merge from Debian [00:38] the 'latest' that got run had to wait for Perl to get out first [00:38] then it ran the autopkgtsts [00:38] ack [00:39] so these are "new" tests that are originated from Debian since.. what, 1.10.0, so the Xenial cycle? [00:39] yeah I dont' see that curve in the OpenSSL curve lists [00:39] for Ubuntu anyways [00:39] gonna check that list vs. Debian and if the list is different then ignroe the check here in ubuntu by commenting out as part of the Delta [00:40] our openssl is too old :) [00:40] :P [00:41] i'm almost certain it is [00:41] yay Debain container time to update you :p [00:43] s/Debain/Debian/ [00:43] *notes to update his autocorrect* [00:45] teward: i retriggered those two diaspora failures, i think they are going further, but we'll see [00:46] OK [00:46] nacc: thanks. [00:46] huh interesting I don't see that SSL curve in Unstable either o.O [00:46] ECDH* [00:47] confirmed the core issue [00:47] # nginx -T [00:47] nginx: [emerg] Unknown curve name "X25519" (SSL:) [00:47] nginx: configuration file /etc/nginx/nginx.conf test failed [00:47] in Zesty [00:47] but works fine in Unstable [00:47] so that's just a curve we don't accept. [00:47] s/accept/have/ [00:47] maybe it doesnt list these newfangled non-ECDH curves in ecparam [00:48] trippeh_: it might not [00:48] it is new in openssl 1.1 fwiw [00:48] ah, that would explain that [00:48] teward: yeah, i think those two diaspora failures will clear on their own now [00:48] we don't roll 1.1 yet I don't think [00:49] nacc: OK. I'm going to go and say "We don't support this curve, because OpenSSL is older than 1.1.0"; how did you suggest I go about 'dropping' the test? [00:49] teward: no, 1.0.2g on zesty [00:49] teward: add a delta, each test is a stanza in d/t/control [00:49] yes but define "delta" as in drop the test or comment out the entire test? [00:49] teward: and then i'd say in the changelog entry (so we know for merges) that once we are at openssl 1.1.0 we can drop it [00:50] teward: totally up to you [00:50] teward: if we did everything with an SCM, then i'd say delete it, but it's a little more self-documenting if commented out [00:50] nacc: I actually have a copy of the packaging in a GitLab instance of my own, so it's sorta version controlled. [00:51] teward: and since you are the maintainer, i think that's ok then to just drop it and you'd know [00:51] nacc: yep, well I'm just going to remove it from d/t/control but leave the test "in there" [00:51] teward: if someone were to come along and do teh team workflow to re-merge it, it'd also be obvious what corresponds to what, i think [00:51] and comment accordingly. [00:51] teward: yeah exactly [00:51] nacc: indeed. Though the team tends to poke me for testing first lol [00:51] teward: :) [00:53] "Unknown error executing apt-key" - thanks, apt-get [00:54] heh [00:56] oops i forgot to put bugfix-only in the changelog fff [00:56] 'accepted' oh cool. [00:58] nacc: I could probably alter the test to try and test the OpenSSL version first. But I'm lazy :P [00:58] I'll just yell at Debian for making me increase the delta :P [00:58] again. [00:58] nacc: looks like the diaspora-installer tests didn't blow up this time heh [00:59] since now it's not erroring on the gems xD [01:00] nacc: what do I need to do if I want to set up autopkgtests for a PPA build before I upload something, say on a local test instance? [01:00] if you know :) [01:11] ah lol, since I was chrooting from a EL7 install, PATH lacked /bin ... [01:11] "wait! no grep!??" [01:12] teward: you can run an autopkgtest against a specific PPA build, one sec [01:12] teward: https://wiki.ubuntu.com/ProposedMigration "Testing aginsta a PPA" [01:16] nacc: yeah, trying to see where it reports that [01:17] nacc: apparently I'm "not authorized" to see the report. or it hasn't run yet, I don't see it queued either. [01:23] teward: i can run it for you probably [01:23] teward: if you have the ppa set up [01:24] teward: and diaspora passed now (excuses is still pending an update) [01:26] nacc: it'll likely rerun and/or explode [01:26] nacc: i was able to *request* the build against the nginx stable PPA. I can't see if it's pending or not [01:26] that's all. [01:26] It didn't say I didn't have privs. to request. [01:26] probably since i'm the admin for that 'group' PPA :P [01:28] teward: oh you'd see it running in the autopkgtest running page [01:28] https://autopkgtest.ubuntu.com/running [01:29] teward: so you uploaded a new version, anyways, right? [01:29] as i see tests running for ubuntu3 [01:47] nacc: yes. [01:47] nacc: -1ubuntu3 has a fix for the autopkgtests. [01:47] and was already accepted somehow. [01:47] it'll probably *still* need pushed by the release team [01:49] nacc: can you check if there's nginx tests against 1.10.3-1+zesty0 or similar in a PPA? [01:49] being run now [01:49] I expect that to blow up actually lol [01:50] (in a PPA) [01:50] 1.10.3-0+zesty0 actually heh [01:50] blah i'm tired [01:51] teward: no, there's only feature freeze on, so it shouldn't need any help in this case [01:51] OK [01:51] teward: and yes, i now see the zesty0 running [01:51] against your ppa [01:51] http://autopkgtest.ubuntu.com/running#pkg-nginx [01:52] cool. [01:59] nacc: yep i see it working thanks [02:00] teward: the only annoyance is you can't see the logs fully until the test finishes and copies over [02:00] teward: which is quite a bit slower than the normal autopkgtests i've found [02:15] nacc: Indeed, though my PPA update workflows are not ones I regularly need to poke so :P [02:15] (nor do I need rapid testing) [02:16] nacc: looks like commenting out that autopkgtest solved the failures for nginx, let's just hope diaspora doesn't blow up in our face again :P [02:16] wth 'nova' regression [02:17] nacc: can you see https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/armhf/n/nova/20170228_013617_86af9@/log.gz and tell me what's dead here? [02:17] it *looks* to me like it's an openscsi / erlang issue [02:18] not even sure *why* nova is triggered by the nginx test though [02:44] teward: i'd guess not your issue [02:44] teward: i'll retry it [02:45] teward: although i agree, i don't know why nova ran [02:46] teward: in fact, i don't see anything installed from -proposed at all except [03:31] nacc: I think you trailed off... [03:31] [2017-02-27 21:46:23] teward: in fact, i don't see anything installed from -proposed at all except ... [03:47] nacc: ^.^ nginx has finally left -proposed and landed in Zesty [03:47] I can rest easy! [04:14] Server Team: I can safely say that the NGINX merge has been completed. Starting with Zesty, we now have ***dynamic module support*** [04:14] future merges should not be as hellish anymore :) [04:15] (cc rbasak, jgrimm, sarnold because reasons, anyone else who cares) ^ [04:19] teward: nice :D now to relax! :D [04:20] sarnold: truth! [07:00] jamespage: did you take a look at building kraken yet? (ceph-11.2.0) would it still seem feasible to get it into zesty? === caribou_ is now known as caribou [08:20] frickler: I did take a peek but then discussed with sage; we don't normally drop the interim releases into Ubuntu [08:20] frickler: so next drop with be luminous in the spring - probably for 17.10 === disposable3 is now known as disposable2 [09:01] jamespage: o.k., thx for the info [09:05] after installing a server with 2 TB disks i get "cannot get disk parameters" when booting the hard drive [09:06] the installation seems to be fine when checking via a live cd [09:06] what could be the cause for it? [09:06] does the server does not see the drives? === tinwood_swap is now known as tinwood [09:17] figured it out, the bootvolume was not set [09:18] where did you set it? === JanC is now known as Guest13435 === JanC_ is now known as JanC [09:30] hello there. I would like to make a refresh of the nova package [09:30] this is different from when I just add a patch in debian/patches [09:30] there is a standard procedure to refresh the upstream version ? [09:42] Good morning. [09:51] zioproto: usually along the lines of: download the new tarball, verify sigs; unpack tarball; rm -rf newtarball/debian/; cp -a oldtarball/debian/ newtarball/debian/ ; rename the tarball to have the .orig.tar.gz name; edit the newtarball/debian/changelog file, add a new entry with new version number, description of what patches remain; fiddle quilt patches from debian/patches/ as needed [09:54] sarnold, ok, so I have to wait the nova folks to create the tarball. I though I could import a git commit from the nova repo [09:57] zioproto: well there's a whole 'git build package' thing going with some way to treat upstream gits as tarballs without the tarballs.. all I know is the ancient stuff :) [10:49] teward: thank you! [11:43] Hm. Upgrading our storage servers to xenial we saw a large performance degradation on our hp hw raids (hpsa), anyone else with similar observations? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1668557 [11:43] Launchpad bug 1668557 in linux (Ubuntu) "Write performance regression severely affecting hpsa controllers" [Undecided,Confirmed] [12:03] maswan: from 3.18.18 to 3.18.21 is already a good narrow diff to look for [12:03] maswan: you said simple dd test is driving this [12:03] yup [12:03] or, well, my collegue across the corridor [12:03] maswan: could you provide the exact command and (to start) an output of "iostat -xtdk 5" that was running over the time [12:04] sure [12:06] ok if I limit iostat to just the relevant device? [12:06] maswan: sure [12:06] (lvm for OS stuff, so lots of dm-*) [12:06] it is just a start to get a feeling where we should go to [12:06] if you write only to a single device, just that [12:07] if you write to an LVM or such just the related devices to your workload [12:07] like top lvm, and the PVs that matter [12:07] no, we write to xfs on /dev/sdb [12:07] for data [12:08] lvm for OS on /dev/sda (different slice, hpssacli output is already attached) [12:08] I'm still reading through the attachments [12:08] * maswan nods [12:08] soon you'll get another. :) [12:09] perfect would be to get the iostat for just the two god/bad kernels that are close [12:12] bad case is in, rebooting for good old kernel. :) [12:14] hm. one case we haven't tried so far in pinning the blame is dd:ing directly to the block device. [12:15] maswan: raw access and/or an alternative fs (like ext4) can be worth a shot for sure [12:15] let me get iostat for the fast case first though [12:15] absolutely [12:15] hm. do you want iostat for the first-good mainline kernel too? [12:16] as I read the bug I thought that comparing 3.18.21-031821.201509020527 vs 3.18.22-031822.201510031227 should be best right? [12:16] yes [12:16] that is minimal delta in terms of patches [12:16] Will do that, just ran it on whatever it was booted on first. [12:16] so I'd compare those until we have a reason to look further [12:16] and then thought harder of what would be best for comparison. :) [12:16] to pick those two will avoid us seeing a lot of "other" noise in logs [12:24] ho hum [12:24] hp servers are slow to boot [12:24] slow is an understatement [12:25] I heard quite a bit of grumbling yesterday when Nikke was bisecting kernel versions and had to wait for a reboot between each test [12:29] There, iostat and command line output from the last fast and first slow 3.18.2* kernels [12:30] * cpaelzer reading [12:31] and on the slow kernel, pretty much identical performance for dd if=/dev/zero of=/dev/sdb bs=256k, possibly slightly slower [12:36] it seems it no more recognized this as a raid [12:37] so the block device layer is holding back requests to merge them [12:37] maswan: you see write reqeust merges per sec ~500 [12:37] maswan: and due to that ~8x bigger write requests [12:37] maswan: which in your case sucks, as the raid below will split it along its stripe size again [12:37] or would have handled all of them in cache already [12:38] cpaelzer: that could indeed explain the suckage [12:38] maswan: you also see that while rq-size is x8 the write await is x60 [12:38] so you can be happy that it is "only" 1/2 instead of 1/7.5 speed [12:38] now lets start to look for changes [12:39] * cpaelzer reading diffs [12:39] thanks [12:39] maswan: IIRC somewhere in /sys there were attrivutes for the devices that flag such things (spinning, cached, ...) [12:39] maswan: while I look for code if you could look in ... [12:39] * cpaelzer is searching [12:42] maswan: get that for both kernels booted on your device (sdb?) [12:42] $ for i in /sys/class/block/sda/queue/iosched/* /sys/class/block/sda/queue/*; do echo $i $(cat $i); done [12:43] there should be no diff between stable kernels, if there is that is another indicator where to look [12:46] yup, working on it [12:46] aka waiting for reboot [12:48] maswan: also you go through page cache with your test (intentionally?) - once time permits you could try if all is the same with oflag=direct [12:48] yet the request merging is a hotter lead which should be pursued first [12:48] OTOH the reboots seems to be what slows you down, so we might collect what we can do each cycle [12:48] well, the first test of dd into a file on xfs is very close to the production case [12:49] which is taking large files from network onto disk (and then spooling them to tape, or the other way around) [12:49] before ingest rate it could handle was line speed 10GE [12:50] ok, if close to the real cae lets stick to that for now [12:50] well, single file all zeros is already a simplifcation of it. but sure, I can try some oflag=direct while I'm booted anyway. :) [12:52] only diff is max_sectors_kb, 4096->512 [12:52] attaching fastmode output to the bug now [12:52] but well that is it maswan [12:53] that is the critical value [12:53] * maswan nods [12:54] and the size close to 8k is in 512b sectors to 4096 (kb) matches the 8*512 [12:54] so probably no need for more narrow dd test cases [12:54] maswan: exactly [12:54] maswan: I still struggle to see the patch that causes it, but there is a workaround for you to test [12:54] maswan: boot the slow kernel and set 512 into that calue [12:54] hmm [12:54] was that a writable one [12:54] uh it might not be [12:55] seems to be writeable [12:55] lets see [12:56] maswan: if you are tuning later for raids you might also consider setting /sys/class/block/sdb/queue/rotational to 0 [12:57] locality with so many disks is kind of inexistant [12:57] but one change at a time [12:57] let me know if setting the smaller max_sectors_kb helped [13:01] maswan: I think I found the change http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=20d74bf29cfae86649bf1ec75038c79a9bc5010f [13:02] it is correct to "fix" it, yet in your case with the drives very likely not having 4k formatting and the strip-size/offset being different it comes to the need of tuning that now [13:02] maswan: let me know how setting 512 worked for you [13:04] cpaelzer: yup, that does indeed make stuff fast on the newer kernel [13:04] yeah [13:05] maswan: for more tuning, have you tried the rotational=0 as well? [13:06] maswan: TL;DR IMHO the controller always announces 4k, instead of being smart and on a certain raid setup drop to the stripe or sector size [13:06] maswan: newer linux "fixes" now pick these values up correctly which makes it slower for you :-/ [13:06] maswan: interested in the rotational flag [13:06] rotational=0 makes very little difference [13:07] it should save cpu time [13:07] maybe 5-10% for kb=512 [13:07] I come from mainframes, every cycle is expensive :-) [13:07] Or make it green, save energy :-) [13:08] maswan: there are other cases where reverting that fix is no option, are you good setting that value as a tuning in your setup? [13:08] maswan: if so I'd close the bug report with that stated [13:09] We're good with setting that in our setup, maybe hpsa authors should be prodded that they shouldn't advertise larger blocks to the kernel than they can (reasonably) handle? [13:10] maswan: as I said they correctly say what they "can" handle, but an option to "advertise what is smart instead of what we can"might be worth [13:10] maswan: if you have contacts at least ask them [13:10] not really [13:11] hm. I guess they might be reading linux-raid though, I'm a long time lurker in there [13:11] Please close it with as much info you can think of on the causes etc [13:13] maswan: done [13:13] maswan: you might use the bug as link in your post [13:14] Yeah, that was my intention [13:14] maswan: I'd be pleased if you could set my user to cc, email is in the launchpad account I posted to the bug [13:14] Sure! [13:16] * cpaelzer is happy that his 12 year old thesis knowledge still applies to todays real world cases :-) [13:16] zul, hello there, are you refreshing some nova stuff today ? [13:25] hm. cc:ing a googled-up hpsa driver contact address too [13:32] guys, looking at the repo git://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/nova how do you do a commit like 8de3da59a8a8c68f76cea78e5319ad18cf8c2531 ? Do you use a tool like git-dsc-commit ? [13:33] when I refresh the nova tag [13:33] should I git checkout in detached head the current latest tag, then make a new commit, and tag it ? [13:33] then I can merge that new tag into stable/mitaka [13:33] is that the idea ? [13:36] I think basak told me this in the past, where are the logs of this IRC channel ? [13:38] hello, I have "/usr/lib/accountsservice/accounts-daemon" at 100% CPU (on one thread), anyway to understand why? (ubuntu xenial) [13:46] Slashman: you might start it with --debug --replace to get a log what it is doing - although I don't know how disruptive that might be [13:46] Slashman: eventually it is supposed to implement a dbus service, so maybe some dbus monotoring might do it as well [13:46] Slashman: but my dbus-foo isn't good enough to guide you n that [13:47] cpaelzer: this server has only one main service : proftpd, I guess that is somewhat related [13:55] zioproto: the tool you are looking for is gbp import-orig [13:56] that allows you to import a new upstream release [13:57] I managed to do it with git [13:57] I just added the git remote of the upstream [13:57] and I did [13:57] git checkout tagname -- . [13:57] then I had to commit manually [13:57] when you do the merge of the new tag into the stable/mitaka ... I should just discard the changes to the .gitignore and to the .gitreview, right ? [13:58] Basically I am trying to create a commit like this one 6de2684e69b8945042c32d185307f10fcf50b24e [14:01] cpaelzer: Btw, Nikke is not quite agreeing that this isn't a hpsa driver bug, giving crappy performance by default. [14:01] but I guess that's more useful in a discussion with upstreams [14:04] coreycb, is there already a LP bug for the new nova release ? https://review.openstack.org/#/c/438570/ [14:06] zioproto, hello I would guess so. zul is working on stable point releases this week, so he would know better than me. [14:07] zul, we have a race between ubuntu making the SRU packages and nova pushing his 13.1.3 tag :) [14:07] please make sure ubuntu packages will be at 13.1.3 [14:14] uhm, I am not sure how to update the pristine-tar branch [14:18] hi all.. I have a simple webpage in folder owned by root:www-data... I created new user test and added this user to www-data group [14:18] but that user still cannot write to that folder... any ideas? [14:18] I logged out, restarted everything... [14:22] ok I did something like pristine-tar commit ../nova_13.1.3.orig.tar.gz 13.1.3 [14:57] ahhhhh [14:57] I restarted from scratch [14:57] gbp import-orig --upstream-version=13.1.3 --debian-branch=stable/mitaka --merge --pristine-tar ../nova_13.1.3.orig.tar.gz [14:59] cpaelzer: looks like my issue is the same as https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1316830 [14:59] Launchpad bug 1316830 in accountsservice (Ubuntu) "/usr/lib/accountsservice/accounts-daemon :: memory and CPU time leak" [High,Confirmed] [15:08] guys is this something valid in Xenial ? 'add-apt-repository -s ppa:ubuntu-cloud-archive/tools' [15:09] I dont see any xenial here: http://ppa.launchpad.net/ubuntu-cloud-archive/mitaka-staging/ubuntu/dists/ [15:14] Âñåì ïðâèåò, êòî ìîæåò ïîìî÷ü ñ ïîñòôèêñîì? [15:14] jamespage, http://paste.openstack.org/show/600790/ ? [15:20] Кто-то с постфиксом может помочь? [15:22] SmOkE_RU, если вы можете говорить по-английски, я могу помочь вам с постфиксе [15:22] (google translate) [15:22] zioproto i think i can) [15:23] so just ask your question in English, it will be easier to get an answer :) [15:24] zioproto i am install postfix for forum phpBB, and cant send emails, in terminal postfix sends mails === iliv_ is now known as iliv [15:26] are you sure phpBB is using postfix to send the mails ? [15:26] sometimes php programs call their out php mta functions [15:27] zioproto yes, phpbb use postfix, i see it in logs [15:28] what do you see in the postfix logs ? [15:28] if you do 'mailq' you see messages in the queue ? [15:30] can we go private? [15:32] better here [15:32] so it is a easy problem [15:32] postfix is running with SSL [15:32] and probably the phpBB is not [15:32] do you need encryption between phpBB and postfix ? [15:33] just configure postfix to work without SSL if they are talking on localhost on the same serer [15:33] server [15:34] hm [15:34] zioproto in main.cf i need disable ssl, right? [15:35] yes, I dont know the extact line to change, but should be easy [15:36] anyone that had built a openstack cloud archive package for xenial can look at this build log ? https://www.dropbox.com/s/40ps3wf849z3b2d/nova_13.1.2-0ubuntu2_amd64-20170228-1528.build?dl=0 [15:36] zioproto, ok i disable ssl, now phpbb in error says: SMTP-server not supported auth [15:37] ok, there is an authentication problem [15:37] just tell postfix to accept mail from localhost [15:38] I think it is in main.cf write mynetworks = 127.0.0.0/8 [15:38] zioproto mydestination = localhost - already set [15:38] what about mynetworks ? [15:38] zioproto, mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 [15:39] from the log do you see what is the address that phpBB uses to connect to postfix ? [15:40] zioproto, Feb 28 18:39:12 truecm postfix/smtpd[8037]: lost connection after EHLO from localhost[127.0.0.1] [15:41] I think phpBB is trying to use a name and password even if it is not needed [15:41] check the config [15:41] make sure is not trying to use a name and passwd [15:41] zioproto method of auth PLAIN or LOGIN? for phpbb [15:42] I have no idea [15:42] :LD [15:42] you need to read the docs for phpbb [15:45] zioproto i dont know how, but it works :D [15:46] zioproto in phpbb i see error, but i recerve test email :D [15:48] great [15:50] teward: err, sorry about that :) -- should have ^W one more time :) [15:50] zioproto thanks for help :) [16:00] no problem ! [16:05] I have no idea when I try to build nova, the build process tries to do 'add-apt-repository -y ppa:ubuntu-cloud-archive/mitaka-staging' [16:11] coreycb, jamespage I found a problem with sbuild-mitaka [16:11] when buidling from xenial [16:11]