[00:39] <Spyidonas> Hey guys, after following this guide " http://www.krizna.com/ubuntu/setup-mail-server-ubuntu-14-04/ " my server can't send emails externaly (for example Outlook.com, Gmail , etc...) The odd thing is that if i send from the external server to my own and reply to that email, the server does send it successfully.
[00:40] <Patrickdk> and the logs are where?
[00:40] <Spyidonas> i tail -f syslog
[00:40] <Patrickdk> that is nice
[00:40] <Patrickdk> but I can't tail it
[00:41] <Patrickdk> so if you want people here to help you :)
[00:41] <Spyidonas> oh you mean to paste the logs. w8.
[00:43] <Spyidonas> That's when i send from my server to external (and i never recieve it)
[00:43] <Spyidonas> http://pastebin.com/wcJ9c0YW
[00:44] <Patrickdk> heh?
[00:44] <Patrickdk> there are lines missing
[00:45] <Spyidonas> And that's when i reply and i recieve it.
[00:45] <Patrickdk> did you get that from /var/log/mail.log ?
[00:45] <Spyidonas> http://pastebin.com/ZTnppVwc
[00:45] <Spyidonas> no i got them from syslog
[00:45] <Patrickdk> to=<spyridonas@live.com>, relay=mx4.hotmail.com[65.54.188.72]:25, delay=2.4, delays=0.29/0.02/1.4/0.76, dsn=2.0.0, status=sent (250  <54F3B259.6030208@buzztera.gr> Queued mail for delivery)
[00:46] <Patrickdk> the email was delievered to hotmail
[00:46] <Patrickdk> using that live.com account
[00:46] <Patrickdk> is that intended?
[00:46] <Spyidonas> Yes but the inbox of the live.com account never recieves it.
[00:46] <Spyidonas> its not on spam etc
[00:46] <Patrickdk> not your problem
[00:46] <Patrickdk> you can see it says
[00:46] <Patrickdk> status=sent
[00:47] <Patrickdk> the hotmail.com server ACCEPTED the email
[00:47] <Patrickdk> what hotmail does to it after that, you will have to ask them
[00:47] <Spyidonas> Then why i recieve the reply and not the send ?
[00:47] <Patrickdk> likely, you just followed that howto guide, and your mailserver isn't setup correctly, dns entries setup ptr, ...
[00:48] <Spyidonas> Same thing on gmail etc.
[00:48] <Patrickdk> are you claiming that hotmail treats all email the same?
[00:48] <Patrickdk> surely not
[00:48] <Patrickdk> they do use spam filters
[00:48] <Spyidonas> I don't think hotmail, tempemails, gmail, yahoo treat their emails all the same way
[00:48] <Patrickdk> the reply email LOOKS completely different
[00:48] <Spyidonas> and i can't send to nobody
[00:48] <Patrickdk> it has a valid hotmail id that references a hotmail email
[00:49] <Patrickdk> what is your servers ip?
[00:49] <Spyidonas> It's a digital ocean server , 178.62.222.144 that's the ip.
[00:50] <Patrickdk> why does it not have a ptr entry?
[00:50] <Patrickdk> mailservers are required to have a ptr
[00:50] <Spyidonas> its a temporary server. Does it need the ptr entry ?
[00:50] <Spyidonas> I thought it can work without it.
[00:50] <Patrickdk> you want to send mail?
[00:50] <Patrickdk> you need a working server
[00:50] <Patrickdk> no ptr == not a working server, for email
[00:51] <Patrickdk> hopefully, you also set a proper helo name, and that works in dns, and matchs your non-existing ptr entry
[00:51] <Patrickdk> and you setup spf and dkim and dmarc entries
[00:51] <Patrickdk> and you do dkim sign every email
[00:52] <Patrickdk> no one has to accept your email
[00:52] <Patrickdk> it's about trust
[00:52] <Patrickdk> hotmail and gmail clearly are seeing all this stuff done wrong, and doesn't trust you
[00:52] <Spyidonas> I was going to do these stuff on the actuall server. Meh i guess i need to set them up again.
[00:52] <Patrickdk> but they are making an exception for replies, cause then the hotmail/gmail user initiated that email
[00:52] <Patrickdk> not you
[00:53] <Spyidonas> Ok i will setup everything then
[06:24] <lordievader> Good morning,
[11:07] <SysTom> Is anyone aware of a working fix for the isc-dhcp-server bug/issue with the permissions of the lease files?
[11:07] <SysTom> https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1186662
[13:47] <Emmanuel_Chanel> Hello!
[13:47] <Emmanuel_Chanel> Someone knows dovecot on Ubuntu well? I want to use both system accounts and virtual mail box on my mail server although I won't use any on the global net.
[13:54] <Emmanuel_Chanel> dovecot dies when I uncommented #!include auth-sql.conf.ext ...
[14:15] <germanstudent> My (IPv6) config file @ /etc/sysctl.d/ won't persist after reboot. The config works on a running system with "sysctl --system" though. Is there some kind of race condition that overwrites /etc/sysctl.d network setting while booting?
[14:15] <germanstudent> correction: the file persists, but not the settings
[14:17] <jamespage> Madkiss, around? wanted to checkin with you re pacemaker corosync stack for vivid (and Debian?)
[14:17] <jpds> germanstudent: Pastebin your sysctl file.
[14:20] <germanstudent> jpds, http://pastebin.com/fUbkuw70 <- saved as 60-ipv6-disable.conf in /etc/sysctl.d
[14:21] <jpds> germanstudent: It's 2015, why are you disabling IPv6?
[14:24] <germanstudent> jpds, because openvpn will only route my IPv4 address and my IPv6 is still public. I can't find a workaround without disabling IPv6 altogether
[14:25] <jpds> germanstudent: 'is still public?'
[14:25] <jpds> germanstudent: Can't you just use ip6tables to block off the ports?
[14:28] <germanstudent> jpds, still public means some services (like netflix e.g.) will see my provider assigned IPv6 and geo locate to Germany, though I'm connected through an US OpenVPN server.
[14:29] <germanstudent> jpds, this is all so complicated. :/ Why doesn't openvpn route all traffic through the desired server by default *sigh* But I might have to visit another channel for this :)
[14:29] <patdk-wk> if your vpn service doesn't offer ipv6, that is fail
[14:30] <patdk-wk> openvpn routes whatever you configure it to route
[14:30] <patdk-wk> oviously since your vpn provider doesn't support ipv6, they don't *request* ipv6 is routed over it
[14:31] <patdk-wk> it would be the same doing anything else, like ipsec, anyconnect, ...
[14:31] <RoyK> germanstudent: is this an old version of openvpn? I beleive I've seen openvpn work well with 14.04
[14:33] <germanstudent> patdk-wk, it is a rented VPN with IPv6 support (with root access). But why isn't it a default behaviour to hide local IPv6 address to the public, even if you specify an IPv4 to connect to?
[14:33] <germanstudent> RoyK it's the current one I guess 2.3.2
[14:33] <patdk-wk> germanstudent, heh? openvpn isn't suppose to default that
[14:33] <RoyK> germanstudent: which ubuntu version?
[14:34] <patdk-wk> that is a misconfigure of your vpn service
[14:34] <germanstudent> 14.04
[14:34] <patdk-wk> or if your side openvpn config
[14:35] <germanstudent> patdk-wk, a VPN service I use has the same misconfiguration them Maybe my dual stack internet access is a factor in this too
[14:35] <patdk-wk> I have been using openvpn with ipv4 and ipv6 over an ipv4 ip for the last 5 years without any problems
[14:35] <RoyK> germanstudent: is this native IPv6?
[14:35] <patdk-wk> but openvpn was not made to *hide my ip*
[14:36] <germanstudent> RoyK, yes. But carrier grade NAT for IPv4
[14:36] <patdk-wk> it was made to do a vpn, so attempting to hide your ip, is out of scope, and needs additional work, exepcially when you have several ip's
[14:36] <patdk-wk> if this vpn service supports ipv6, I would wonder why your not using it
[14:37] <germanstudent> patdk-wk, well, but it was made to connect to a network and communicate to that network solely, right? :/
[14:37] <patdk-wk> no
[14:37] <patdk-wk> it was made to protect data from point A to B
[14:37] <patdk-wk> communicate solely or not, is optional
[14:38] <patdk-wk> normally defined as, split horizon
[14:38] <germanstudent> patdk-wk, hm. thanks for your help. I guess I have to write a forum post or something. No IPv6 setting I tried seem to work
[14:38] <germanstudent> What's weird is that this doesn't happen with Mac or Windows.
[14:41] <RoyK> germanstudent: that's strange indeed
[14:41] <patdk-wk> is it a dns issue?
[14:42] <patdk-wk> maybe the dns server over the vpn doesn't do ipv6? possible maybe
[14:42] <patdk-wk> and ubuntu keeps falling back to the local dns
[14:42] <germanstudent> patdk-wk, I have to do some more tests, before I can say more. But I entered googles dns in the openvpn config
[14:42] <RoyK> germanstudent: do you have ipv6 dns servers in resolv.conf?
[14:43] <germanstudent> RoyK, no, IPv4
[14:43] <RoyK> germanstudent: add v6 servers, then
[14:43] <germanstudent> Okay, thank you
[14:44] <RoyK> 2001:4860:4860::8888 and 2001:4860:4860::8844 if you're using the standard google dns servers
[14:44] <germanstudent> Will try
[16:55] <sarthor> Hi, I have problem of language right to left, here is link which show some help, but as a newbie I am not able to understand, If someone can help where to write that coding which link shows. here is link http://mpcabd.igeex.biz/python-arabic-text-reshaper/
[17:38] <sarthor> Hi, I have problem of language right to left on ubtuntu-server , here is link which show some help, but as a newbie I am not able to understand, If someone can help where to write that code or how to follow, the link shows. link http://mpcabd.igeex.biz/python-arabic-text-reshaper/
[17:38] <Emmanuel_Chanel> Someone can help me? I tried to install a mail server based on this page: https://www.exratione.com/2012/05/a-mailserver-on-ubuntu-1204-postfix-dovecot-mysql/ I want to use both my system account, different from that. And I got this result: http://pastebin.ca/2947074
[17:39] <Emmanuel_Chanel> What can I do for solving it?
[17:53] <sarnold> Emmanuel_Chanel: check demsg for more segvs; you may have bad memory
[18:32] <bekks> Emmanuel_Chanel: So you are using 12.04?
[18:36] <Emmanuel_Chanel> No... 14.04 now...
[18:36] <Emmanuel_Chanel> But not understanding the mail server well, I feel that tutorial very good when I installed it on Ubuntu 12.04.
[18:39] <bekks> Emmanuel_Chanel: Which doesnt mean it works on 14.04.
[18:40] <Emmanuel_Chanel> Right...
[18:41] <bekks> Emmanuel_Chanel: Try this one first: https://www.exratione.com/2014/05/a-mailserver-on-ubuntu-1404-postfix-dovecot-mysql/
[18:43] <Emmanuel_Chanel> Oh, nice! I didn't know that. I try.
[18:46] <Emmanuel_Chanel> Thank you very much authough I haven't got a result yet.
[19:16] <mgagne> hallyn_: ping
[19:20] <xibalba> Hey folks, I'm seeing this in my `dmesg` `[233478.288816] TCP: TCP: Possible SYN flooding on port 8080. Dropping request.  Check SNMP counters.`; Can I disable the check for SYN Flooding on port 8080?
[19:21] <xibalba> hmm i dont see syn_flood in my iptables --list
[19:21] <patdk-wk> why would there be?
[19:22] <xibalba> i thought iptables would be handling the above message regarding syn flooding
[19:22] <patdk-wk> why?
[19:22] <patdk-wk> don't see anything in that message that talks about iptables
[19:22] <xibalba> ok it's a kernel option then?
[19:22] <patdk-wk> the question is, why do you ahve a synflood?
[19:23] <patdk-wk> are you getting dos?
[19:23] <xibalba> no
[19:23] <patdk-wk> do you just have a crapload of ligit traffic
[19:23] <patdk-wk> or is your application gone completely nuts
[19:23] <xibalba> it's just a bad client side app i need to get fixed, but i need to disable that synflooding check for the time being
[19:23] <xibalba> ^^ complete nuts
[19:23] <xibalba> a javascript websocket client connecting to the websocket server
[19:23] <patdk-wk> use sysctl and disable it though
[19:23] <patdk-wk> but that is likely to have all kinds of fun issues
[19:23] <xibalba> do youknow which options?  i just did syctl-a |grep syn to gleam the list
[19:23] <xibalba> oh i know, it's temporary
[19:24] <patdk-wk> net.ipv4.tcp_syncookies likely is what you want
[19:24] <patdk-wk> but this doesn't *fix* anything
[19:24] <xibalba> 10-4
[19:24] <patdk-wk> it just means the kernel won't start attempting to figure out ligit from non-ligit requests
[19:25] <patdk-wk> the problem is, your app isn't accepting connections fast enough
[19:25] <patdk-wk> overflowing the syn_backlog
[19:25] <xibalba> right, we're trying to diagnose that now :)
[19:25] <xibalba> yeah, all my received queues in netstat are 503 too
[19:25] <patdk-wk> therefor making the kernel not know what to do, except drop connections
[19:25] <xibalba> w/120+ connections from 1 client for a websocket javascript client
[19:25] <xibalba> so we know it's borked
[19:25] <patdk-wk> increasing your backlog would help, kindof :)
[19:25] <xibalba> i dont think it's being hit yet, it's 512
[19:26] <xibalba> netstat -an |grep -iest |wc -l , is less than 200
[19:26] <patdk-wk> well, the kernel settings ONLY set the max
[19:26] <patdk-wk> the application sets what it wants
[19:26] <xibalba> ah
[19:26] <patdk-wk> normally they are around like 10/50/80/...
[19:26] <patdk-wk> not normally very large unless you override
[19:26] <xibalba> let me see., this is a puma app
[19:29] <hallyn_> mgagne: hi
[19:29] <mgagne> hallyn_: hi
[19:29] <mgagne> hallyn_: I got the patches, can you guide me into proposing them?
[19:29] <mgagne> hallyn_: https://gist.github.com/mgagne/95046681c59e4e20989c
[19:32] <hallyn_> mgagne: now this is for in cloud archive right?
[19:32] <RoyK> mgagne: download the source code for the package, patch the code, build it and reinstall the package from the one you built. it's not really as straight forward as downloading a patched windows driver :P
[19:32] <Madkiss> hello jamespage
[19:32] <mgagne> hallyn_: UCA is sub-product of Ubuntu itself, the packages themselves come from Ubuntu release like 13.10, 14.04, etc.
[19:33] <Madkiss> jamespage: how can I help?
[19:33] <mgagne> hallyn_: they might have UCA specific fixes but IMO, this one isn't specific to UCA
[19:33] <hallyn_> mgagne: right, but we are being very strict about what upgrades we support (bc otherwise it becomes crazy-fragile), so i'm wondering whether this change should be specific to cloud archive
[19:33] <hallyn_> zul: jamespage: ^ around?
[19:33] <hallyn_> mgagne: th equestion is do we support upgrading from UCA to standard ubuntu archive of newer release
[19:33] <zul> hallyn_:  yeah
[19:33] <mgagne> hallyn_: right, I don't know the specific of the policies
[19:34] <hallyn_> mgagne: anyway, thank you for the patch;  we definately will fix it somehow that fixes it for UCA,
[19:34] <hallyn_> i'm only trying to find the right place
[19:34] <hallyn_> mgagne: there's a bug# for this right?
[19:34] <mgagne> hallyn_: 1425619
[19:34] <mgagne> hallyn_: AFAIK, there is no UCA for juno/icehouse
[19:35] <mgagne> hallyn_: because trusty ships with icehouse already
[19:37] <hallyn_> mgagne: so what are you trying to upgrade from/to?  (release+archive)
[19:37] <hallyn_> this is all greek to me so getting my bearings and hoping zul is watching
[19:38] <zul> mgagne: https://wiki.ubuntu.com/ServerTeam/CloudArchive
[19:38] <mgagne> hallyn_: I'm running uca/precise/icehouse. We have nodes running QEMU 1.5 from uca/precise/havana (for various reasons).
[19:39] <hallyn_> sand you're upgrading between those two?
[19:39] <mgagne> hallyn_: UCA is just a backport of packages from a Ubuntu release supporting a specific OpenStack version.
[19:39] <mgagne> hallyn_: so for Havava, packages were backported from 13.10 to 12.04 into UCA
[19:41] <hallyn_> right, 13.10 is no longer supported ,and migration in archive was only ever supported from p->q, q->r, r->s, not from p->s
[19:41] <mgagne> hallyn_: to make the migration work, the patch needs to go in QEMU 2.0 (destination), you don't need to patch the source of the migration
[19:41] <hallyn_> so i think we want the fix straight into the uca
[19:42] <hallyn_> right, but it's hard to SRU something for something that is not supported in archive, given the strict SRU restrictions.
[19:42] <hallyn_> i'll talk to jamespage when he's around, and handle it somehow
[19:42] <mgagne> QEMU 2.0 is part of 14.04. someone running saucy cannot upgrade to trusty unless trusty is patched
[19:42] <hallyn_> (notes taken)
[19:42] <jamespage> hallyn_, mgagne is correct - for icehouse everything is just in trusty
[19:43] <hallyn_> jamespage: yeah but you can add a delta
[19:43] <jamespage> hallyn_, where?
[19:43] <hallyn_> in icehouse
[19:43] <jamespage> but that's just 14.04
[19:43] <jamespage> no where else to make a delta
[19:43] <hallyn_> jamespage: ok, do you mind filling in SRU justfication for bug 1425619 ?
[19:44] <hallyn_> jamespage: thing is when we discussed the p->t migration (with infinity and others) it was almost decided it shoudn't be supported at all;  it was then decided we would do very lmited support
[19:44] <hallyn_> but really the patch looks good,
[19:44] <jamespage> hallyn_, well officially we support precise+icehouse cloud archive to trusty migration
[19:45] <mgagne> hallyn_: p->t support was already added with a very similar patch
[19:45] <mgagne> hallyn_: see related bug https://bugs.launchpad.net/bugs/1291321
[19:45] <hallyn_> no wait,
[19:45] <jamespage> I'll be around in about 1.5 hrs
[19:45] <hallyn_> i'm aware, i pulled that patch :)
[19:46] <mgagne> hallyn_: thanks for that work bth =)
[19:46] <mgagne> btw*
[19:47] <hallyn_> oh i didn't do the patch myself :)  ok, i think your patch looks good;  i'll try to sru it
[19:47] <hallyn_> thanks mgagne
[19:47] <mgagne> thanks!
[19:47] <mgagne> I guess I don't need to mention that I tested it and it works =)
[19:48] <hallyn_> :)  but i'm glad you did
[19:48]  * hallyn_ out a bit, biab
[19:52] <Emmanuel_Chanel> bekks: Same error occurred again...
[19:53] <bekks> Emmanuel_Chanel: So take a look at the dovecot logs and config, for investigating its crashes.
[20:58] <jamespage> Madkiss, hey - thanks for the pointer to your HA ppa - most useful
[20:59] <roaksoax> it would have been nice to grab those from debian too :)
[21:02] <Madkiss> jamespage: yw
[21:03] <jamespage> Madkiss, are you still maintaining corosync/pacemaker in Debian?
[21:07] <Madkiss> jamespage: well. sort of.
[21:28] <jamespage> zul, are you still ontop of that eventlet version bump?
[21:28] <zul> yeah im on it