[00:03] <NTQ> patdk-wk: This is my master.cf: http://paste.debian.net/135565/  I only added the last two lines and activated "submission inet ..." and "smtps inet ..."
[00:03] <NTQ> The rest was the standard master.cf from the repository
[00:06] <patdk-wk> ok, in main.cf
[00:06] <patdk-wk> remove smtpd_sasl_auth_enable = yes
[00:07] <patdk-wk> in master.cf change, smtpd_client_restrictions to smtpd_recipient_restrictions
[00:07] <patdk-wk> in main.cf, remove smtpd_tls_auth_only = yes, and in it's place put, smtpd_tls_security_level = may
[00:08] <patdk-wk> oh wait hmm
[00:08] <patdk-wk> wrong one
[00:08] <patdk-wk> I mean, smtpd_use_tls = yes, remove that one
[00:08] <patdk-wk> leave the smtpd_tls_auth_only = yes
[00:09] <NTQ> okay
[00:09] <patdk-wk> and for love of god
[00:09] <patdk-wk> remove your server name from mydestination
[00:10] <patdk-wk> unless you don't have it configured in postfixadmin at all
[00:10] <NTQ> Oh yes. it did that already
[00:10] <NTQ> If found it our some hours ago
[00:10] <patdk-wk> oh, updated pastebin would be useful :)
[00:10] <patdk-wk> so I'm working with the correct info
[00:11] <NTQ> sorry. the only change was mydestination = localhost
[00:19] <NTQ> The good thing is that there are no more erros in mail.err or mail.log after restarting up dovecot and postfix. But there are some authentification failures in auth.log from for ruser=webmaster and ruser<EMAIL_ADDRESS>with my IP address in rhost.
[00:19] <patdk-wk> that file doesn't matter at all
[00:20] <NTQ> And there are currently a lot of 'POSSIBLE BREAK-IN ATTEMPT!' from stocazzo.stocazzo.com with many different user names.
[00:20] <patdk-wk> yes, but none of that matters
[00:21] <patdk-wk> do those lines even say dovecot or postfix?
[00:21] <patdk-wk> everything looks good, from what I see
[00:21] <NTQ> Dec  9 01:12:21 loft1234 auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot<EMAIL_ADDRESS>rhost=<IP_ADDRESS>
[00:22] <NTQ> And some without @testdomain.de
[00:22] <patdk-wk> is that your test?
[00:23] <NTQ> The test with thunderbird
[00:23] <NTQ> Thunderbird tries to find the correct configuration.
[00:24] <patdk-wk> why is it doing an auth against pam?
[00:24] <patdk-wk> I thought you where using postfixadmin?
[00:24] <Ironlenny> Has anyone setup port forwarding for kvm?
[00:24] <NTQ> I do.
[00:24] <patdk-wk> then there should be no lines in auth.log about dovecot or postfix
[00:24] <patdk-wk> so you have dovecot configured to auth against PAM instead of postfixadmin mysql
[00:25] <NTQ> No. I guess not. I created many mysql_virtual_*.cf files with mapping for the mysql database.
[00:26] <NTQ> And there were configured in main.cf
[00:26] <patdk-wk> yes, but that is postfix, not dovecot
[00:28] <patdk-wk> http://sourceforge.net/p/postfixadmin/code/HEAD/tree/trunk/DOCUMENTS/DOVECOT.txt
[00:28] <patdk-wk> note the, userdb/passdb sections
[00:28] <patdk-wk> and probably the whole dovecot sql setup section
[00:30] <NTQ> Thank you. But for now I have to go to bed. It's 1:30 am ;)
[00:37] <NTQ> I guess the main problem is that I used a very old manual.
[00:48]  * keithzg is slowly being driven crazy by the zero result of adding blacklist_from lines to the spamassassin local.cf file . . .
[00:57] <EuaD> howdy everyone, is it recommended to have iptables rules or no on a WAN facing server running apache, nginx, teamspeak, mumble, minecraft
[00:57] <teward> EuaD: if there's something internet facing i'd set a default DROP or REJECT rule that doesn't match the specific ports you have listening
[00:58] <sarnold> EuaD: even though that might feel very porous, it still feels like a good idea to reject whatever that system shouldn't be doing, to help avoid e.g. abuse complaints or overage charges etc
[00:59] <teward> indeed.
[00:59] <EuaD> for example, znc is currently facing the internet on port 60,000. can you explain what you mean by your first statement
[00:59] <teward> EuaD: mine, or sarnold?
[01:00] <EuaD> either or. lol   so basically i just add a rule that drops all traffic for any port if it's not port 60,000
[01:00] <EuaD> in my example
[01:00] <teward> um...
[01:01] <teward> EuaD: lemme show you an example of what I meant, because my rules are a tad overkill but structured for a reason
[01:01] <sarnold> EuaD: "feels very porous", you've got two web servers which are probably pretty decent but both are large codebases, teamspeak which is probably insufficiently reviewed, mumble, same thing, and minecraft, which is gigabytes of java if the rumours are true...
[01:02] <teward> sarnold: s/if the rumors are true/of which the rumors are true/
[01:02] <sarnold> EuaD: each one represents an attack surface, and some of them are probably not well-audited
[01:02] <teward> i can confirm it eats memory
[01:02] <teward> agreed with sarnold
[01:02] <teward> effectively this is my ruleset:  https://pbin.dark-net.net/view/raw/7ac1a067
[01:02] <EuaD> i've never bothered running a software firewall because my current xubuntu 14.04.1 server is behind a hardware firewall
[01:02] <teward> ignore the logging section, i was experimenting with Splunk :P
[01:02] <teward> ooop, Xubuntu 'Server'
[01:02] <teward> GUI adds another exploit surface
[01:03] <EuaD> how does Xorg add an exploit surface?
[01:03] <sarnold> EuaD: you might want to look into UFW; install it, add some "allow" for the different services you need (do not forget ssh) and then enable it. it's also useful to install restrictive -outbound- rules, too, to avoid being a source of spam or attacks or something incase one of those services -is- hacked but the attacker doesn't get root
[01:03] <teward> effectively though, what you have running is pretty 'huge' in terms of attack surface - minecraft, apache, and nginx being three big ones
[01:03] <teward> agreed with sarnold
[01:04] <teward> (the rules I posted were for this local system, but having the restrictive rules on both sides are a good idea)
[01:04] <sarnold> EuaD: xorg -used- to run wide open on tcp by default. there's literally hundreds of opportunities for root bugs if X is installed
[01:04] <teward> (and in my case, outbound is restricted by a hardware firewall)
[01:05] <EuaD> sarnold, ah i didn't know that. does ubuntu do that by default with Xorg?
[01:06] <sarnold> EuaD: I don't see any TCP sockets for trusty's X, it's probably safe by default
[01:07] <teward> sarnold: mind if I poke you about something, maybe see if you can get someone in the merge reviewers to poke it because of a security concern (POODLE)?
[01:07] <sarnold> teward: sure, what is it?
[01:07] <EuaD> sarnold, yeah, it's got -nolisten tcp by default
[01:08] <sarnold> EuaD: good good. do note the permissions on /usr/bin/X though, once an attacker has local access on the box, there's an opportunity to abuse X to gain root privs
[01:09] <teward> sarnold: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1399967 is the merge request - i say security centric with regard to POODLE because it further mitigates POODLE SSL risks and adds a couple extra security measures WRT SSL (such as prefer-server-ciphers) to the nginx.conf which is then global in nginx.
[01:09] <teward> (the merge is only targeted at Vivid, none of the fixes are on my backport radars, except for the PPAs)
[01:09] <teward> sarnold: https://code.launchpad.net/~levlaz/ubuntu/precise/nginx/fix-for-1370478/+merge/243890 is the other thing on the radar, and that user reached out to me after filing it asking me to take a peek
[01:10] <teward> but of course my Wireshark project is a lot higher on the radar than that
[01:10] <teward> that second one needs sec team review
[01:10] <teward> (the bug is about incorrect cached SSL)
[01:11] <teward> sarnold: and i'm sorry to keep adding things to your radar :P
[01:11] <sarnold> teward: nice merge, do note the '[atches' typo though
[01:11] <teward> oopsies
[01:12] <teward> that's an easy fix, gimme 2 minutes
[01:13] <EuaD> is it easy to use a guide for setting up a LAMP server but instead of apache, use nginx?
[01:13] <teward> wwwhoopsies, timeout o.o
[01:14] <teward> sarnold: i might have to go stab #launchpad or canonical sysadmins - all uploads're timing out
[01:16] <teward> aaand i had to use firefox, because chrome derped
[01:16] <teward> sarnold: updated that, thanks for catching that typo :)
[01:16] <sarnold> ugh I hate that kind of solution :)
[01:16] <sarnold> hehe
[01:16] <sarnold> thanks teward
[01:17] <teward> sarnold: and better note: this is my *second* merge - first was to get -4ubuntu1 in :)
[01:17] <teward> ooopsies
[01:17] <teward> i forgot the bug number >.>
[01:17] <teward> grrrrrrr
[01:17] <sarnold> d'oh :)
[01:18]  * teward beats himself and apologizes for the noise in the attachment upload
[01:18] <teward> sarnold: so far these merges have worked easily, and it's easier going from -4 to -5 :P
[01:19] <sarnold> could be worse, could be an 'apport-report NNNN' for e.g. X, those things are -noisy- :)
[01:19] <teward> urgh...
[01:19] <teward> yeah tell me about it
[01:19] <sarnold> thirty emails later...
[01:19] <teward> i see enough errors.u.c reports about the packages from nginx upstream...
[01:19] <teward> it annoys and irks me... >.<
[01:19]  * teward checks every day :/
[01:20] <teward> it irks me that so many people use the upstream repository and not the PPAs - it causes a lot of package conflicts during updates and such
[01:20] <teward> only bare minimum Debian policy compliant, AFAICT
[01:20] <teward> at least the PPAs inherit the Debian policy compliance from Debian
[01:21] <sarnold> both have their place; some people just want upstream nginx regardless of distro they use to host it and other people want good distro integration regardless of which webserver they pick
[01:21] <teward> sarnold: the other merge request is not mine, but was on my radar because i was pinged about it.  Pinged you in -hardened too, so it'd end up on your radar
[01:21] <teward> mhm
[01:21] <sarnold> teward: thanks for the re-ping, I hadn't made it back to that tab yet since this morning, heh
[01:22] <teward> sarnold: oh, another note on -5ubuntu1 is it brings in code in the scripts to remove naxsi extras from nginx-common, apparently some of the config files still were left behind
[01:22] <teward> (and now actually finds the files and removes them if still present so purges work and such...)
[01:22] <sarnold> teward: I'm happy to see naxsi gone, I didn't care for its coding style much iirc
[01:22] <teward> sarnold: and no problem
[01:22] <teward> sarnold: naxsi was a PITA... it was NOT trivial to maintain
[01:22] <sarnold> .. a little worried about config files being deleted but there's no great solution there, either, is there
[01:22] <EuaD> sarnold, i see what you're saying. i don't really understand how an attacked would gain access to the local machine but i see what you're saying
[01:23] <teward> sarnold: no, but i mean that the files were left as remnants in nginx-common and such, so it's extra crap, but meh
[01:23] <sarnold> EuaD: well, once an attacker has hacked a process they've become a 'local' attacker; having access to all the things on the filesystem can open up all kinds of opportunities for evil
[01:24] <teward> sarnold: the biggest issue is one we might need to take up with the higher ups - Lua is still not 'updated' to 5.2, so we run into the problem of Lua possibly needing removed by the next LTS - because the Lua third-party module doesn't look like it's going to get support for later variants of Lua...
[01:25] <EuaD> sarnold, hacked a process?
[01:25] <sarnold> teward: blech.
[01:25] <teward> sarnold: indeed - not pretty
[01:26] <teward> the problem being that we can't keep older Lua in main forever...
[01:26] <sarnold> EuaD: yeah, gained control over the process, say a buffer overflow or format string bug or java class loader bug, etc..
[01:26] <teward> (i think this was even discussed during the MIR)
[01:26] <sarnold> teward: yeah, though to be fair we've never done a security update on lua. so, as far as actual -costs- go, it might not be terrible to keep 5.2 around two years longer than we've already committed.
[01:27] <teward> s/5.2/5.1/
[01:27] <teward> 5.2 is incompatible
[01:27] <sarnold> ah right
[01:27] <teward> https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1324062 being relevant
[01:27] <teward> sarnold: you're right, and that was discussed at the time of the LTS release and the MIR.
[01:28] <teward> i think it was discussed in -devel or -release at one of those points
[01:28] <teward> and the decision to keep 5.1 in main was made to not have to butcher the featuresets
[01:28] <sarnold> and generate an even larger delta with debian
[01:28] <teward> (and upstream on the LUa module has basically said that 5.2 is incompatible with 5.1", and essentially has also said that they won't have 5.2 support for the forseeable time
[01:28] <sarnold> ditchin naxsi is a big help there though :) hooray
[01:28] <teward> indeed
[01:29] <teward> sarnold: sooooo much less crap for me to maintain
[01:29] <sarnold> \o/
[01:29] <teward> also FYI, i'm still seeking PPU for nginx i just haven't had time to submit the application.
[01:29] <teward> also my schedule prohibits me from being present at DMB meetings which adds additional strife :/
[01:30] <EuaD> sarnold, wow, i had no idea. lol
[01:30] <EuaD> i currently only use nginx for it's rtmp module, i love that module. :)
[01:31] <sarnold> EuaD: ideally, most people wouldn't ever have to know :) but hackers are currently on the leading edge of this arms race...
[01:47] <teward> sarnold: i assume security updates still need security team review regardless of PPU rights, right?
[01:47] <sarnold> teward: right, all security updates must go through the security ppa
[01:49] <teward> that's what i thought
[01:50] <teward> grrr evil client
[01:50] <teward> sarnold: fortunately i lurk -hardened and end up being all "Hey, incoming security fix for CVE-XXXX-XXXX in nginx, here's the bug!  <link>"
[01:50] <teward> i bet that gets old after a while, but meh
[01:50] <teward> :P
[01:51] <sarnold> teward: it's helpful, our normal cve triage process can't get everything in a timely fashion
[01:52] <teward> mhm
[01:52] <keithzg> patdk-wk: I feel like postfix is taunting me; every action I'd *want* it to take mentions in the documentation "This feature is not supported with smtp header/body checks" :P
[01:52] <teward> sarnold: at some point it probably becomes annoying.  Anyways, I digress.
[01:53] <Patrickdk> heh?
[01:53] <Patrickdk> what do you want to do?
[01:55] <keithzg> I'd be fine with DISCARD or REJECT, and if I had to I guess I could work with (although it seems like more effort than something so simple should be) FILTER or HOLD or REDIRECt and set up some script or such to then deal with it.
[01:56] <keithzg> Literally all of those are listed as not working with header or body checks!
[01:57] <keithzg> The only thing header checks can apparently do is DUNNO, IGNORE (which only deletes the current line), INFO, PREPEND, REPLACE and WARN.
[01:57] <Patrickdk> you must be reading something wrong
[01:58] <Patrickdk> ah, yes you are completely reading this wrong
[01:58] <Patrickdk> smtp!=smtpd
[01:58] <Patrickdk> exactly how do you redirect/filter/drop/hold, email CURRENTLY leaving your server?
[01:58] <Patrickdk> you do it when your *receiving* it, incoming
[01:59] <keithzg> ahh, so it's saying this isn't valid for *outgoing* checks, eh?
[01:59] <Patrickdk> when using smtp_header_checks and smtp_body_checks
[01:59] <Patrickdk> not smtpd header_checks and body
[01:59] <Patrickdk> most people never use smtp_header_checks
[02:00] <Patrickdk> I have one system I use it on though
[02:01] <keithzg> Fair enough. And I did finally see an email come through that met the criteria, and the log shows it rejected just fine, so it does indeed work. Thanks!
[02:02] <keithzg> Err, don't suppose I could bug you for why blacklist_from in my spamassassin conf appears to do nothing, then? I can't see any explanation in the documentation of quite how it's supposed to act (I would assume either outright blocking or just adding to the spam score, but neither appears to be happeneing from what I can see in logs).
[02:03] <keithzg> To be specific, I'm defining these lines in my local.cf, and spamassassin --lint seems to have no issues so I presumably have the syntax correct, at least.
[02:04] <Patrickdk> what should have matched blacklist_from and didn't?
[02:04] <Patrickdk> blacklist* adds 100points to the score
[02:06] <keithzg> I tried "blacklist_from<EMAIL_ADDRESS>since I'm seeing a *ton* of spam from .link domains and I've never heard of anyone using those legitimately yet; I also tried "blacklist_from<EMAIL_ADDRESS>since a fair number from there seem to be showing up.
[02:07] <sarnold> are you sure those are legal patterns for those fields?
[02:07] <sarnold> they look like shell globs rather than regex rules
[02:07] <Patrickdk> heh? I bought a .link domain a month or two ago
[02:08] <pmatulis> no mail for you
[02:08] <keithzg> sarnold: good thought, but I had read that globs are actually accepted these days in the postfix documentation
[02:08] <Patrickdk> blacklist_from<EMAIL_ADDRESS>[02:08] <Patrickdk> blacklist_from<EMAIL_ADDRESS>[02:08] <Patrickdk> works for me :)
[02:08] <sarnold> keithzg: aha :) back to lurking :)
[02:08] <Patrickdk> keithzg, are you sure the FROM address is set to that? or the env from?
[02:10] <Patrickdk> header SOMETLD_ARE_BAD_TLD          From:addr =~ /\.(link|pw)$/
[02:10] <Patrickdk> describe SOMETLD_ARE_BAD_TLD        .PW & .LINK TLD Abuse
[02:10] <Patrickdk> score SOMETLD_ARE_BAD_TLD           10.0
[02:10] <Patrickdk> but what you really want is: http://www.pccc.com/downloads/SpamAssassin/contrib/KAM.cf
[02:12] <keithzg> Patrickdk: ooh, thanks; yeah, I'm kindof fumbling around here, that looks like a great rule/conf set to crib from :)
[02:15] <keithzg> Or I suppose just to wget via a cron job, heh
[02:15] <Patrickdk> heh
[02:16] <Patrickdk> sometimes he updates it daily
[02:16] <Patrickdk> but most of the time it can go weeks
[08:39] <praktikant> hi@ll, is there a how-to for a ubuntuServer behind a firewall (not a personal firewall) .... what i have to do for "apt-get"?(i just need the configuration of ubuntu, nothing else.)
[08:53] <lordievader> Good morning.
[09:26] <mardraum> TheTrainee_: don't ask a question then change your nick
[09:27] <mardraum> TheTrainee_: there is no howto, it would depend what is blocked. If you can set a proxy server apt-get can use that, which is a common scenario.
[09:55] <TheTrainee_> sry, of nicknamechange.
[09:55] <TheTrainee_> i got it.
[09:56] <TheTrainee_> there where a testing of the firewall .... i didn't know. noone told me.
[09:56] <TheTrainee_> everything is now allright. :)
[09:57] <TheTrainee_> but thx so far.
[09:57] <TheTrainee_> i am hunting for my luck now.
[09:58] <TheTrainee_> have a nice day. ;)
[09:58] <TheTrainee_> bb.
[10:09] <gnuoy> jamespage, Having looked at python-logutils, both ubuntu patches can be dropped. So, I've created Bug #1400649
[10:25] <NTQ> Hi. I'm back.
[10:26] <NTQ> patdk-wk:
[10:39] <jetsaredim> if I opt for virtualization server on the server install menus - what does that actually install
[12:03] <jamespage> gnuoy, one query on that sync
[12:03] <jamespage> see bug
[14:35] <zul> jamespage:  ping so oslo.messaging
[14:35] <jamespage> zul, hello
[14:35] <zul> jamespage:  1.5.1 is out today and have it packaged but the kombu tests fail because a newer kombu version is needed
[14:36] <zul> jamespage:  ran the tox tests with our version of kombu and I get the same test failures in my sbuild
[14:36] <jamespage> zul what does it need?
[14:37] <jamespage> zul, I see a .24
[14:37] <zul> kombu: >= 2.5.0 but it fails with 3.0.24 but works with >= 3.0.24
[14:39] <jamespage> zul, lemme deal with it now
[14:39] <zul> jamespage:  ack
[14:39] <jamespage> can' t progress on any of my other challenges today...
[14:43] <jamespage> zul, uploaded - has new support for qpid but not enabling that
[14:43] <zul> jamespage:  cool
[14:50] <jamespage> zul, or maybe not
[14:50] <jamespage> letme have another run at that
[14:54] <jamespage> zul, need a new amqp - fixing now
[14:54] <zul> jamespage:  ack
[15:03] <jamespage> zul, I have a list of picks for zmq that we  want as well
[15:03] <zul> jamespage:  okie gimme :)
[15:04] <zul> er...please
[15:04] <jamespage> zul, https://review.openstack.org/#/c/128233/
[15:04] <jamespage> zul, https://review.openstack.org/#/c/129114/
[16:08] <Justice> Are there any program that allow for testing of traffic shaping?
[16:08] <Justice> similar to glasnost
[16:10] <Justice> traffic shaping and/or peering
[16:16] <hariom> Hi, I am in the need of urgent help. I am upgrading 12.04 to 14.04 but in the mid way of fetching packages, I am getting error: Err http://security.ubuntu.com/ubuntu/ trusty-security/main linux-headers-3.13.0-40 all 3.13.0-40.69                   Connection failed [IP: <IP_ADDRESS> 80]
[16:16] <hariom> What should I do?
[16:25] <lordievader> hariom: Figure out why you cannot connect to that ip/port.
[16:37] <hariom> lordievader: I am able to ping to that ip from the same server
[16:38] <lordievader> hariom: Can you connect to port 80?
[16:41] <hariom> lordievader: how do I connect?
[16:41] <Justice> bump
[16:42] <jamespage> zul, kombu has a racey redis test - but it should appear shortly
[16:42]  * jamespage hit the button of despair
[16:42] <zul> jamespage:  okie dokie
[16:42] <zul> jamespage:  rabbit hole?
[16:43] <lordievader> hariom: You can check with nmap or netcat or something like that.
[16:44] <hariom> ok. I will back. Need to step out for dinner.
[16:45] <jamespage> zul, a bit
[16:51] <jamespage> kickinz1_mob|off, smoser: nice work guys
[17:25] <jamespage> zul, I also need to create a zmq-receiver binary package for oslo.messaging - have you uploaded yet?
[17:26] <zul> jamespage:  i havent
[18:08] <jetsaredim> can someone please tell me where to get an updated dkms for 14.10?
[18:09] <jetsaredim> one that fixes the bash/sed issue?
[18:11] <adam_g> zul, jamespage heads up, may want to rebase horizon 2014.2.1 to include https://review.openstack.org/#/c/140358/
[18:11] <jamespage> adam_g, awesome
[18:12] <jamespage> coreycb, ^^
[18:12] <coreycb> adam_g, jamespage, thanks for the notice, will do
[18:13] <zul> adam_g:  awesome-o
[18:22] <hariom> I am getting error while upgrading to ubuntu 14.04: Err http://in.archive.ubuntu.com/ubuntu/ trusty-security/main linux-headers-3.13.0-40 all 3.13.0-40.69   Connection failed [IP: <IP_ADDRESS> 80]
[18:22] <hariom> I have tried another mirror but same result. How to trouble shoot.
[18:22] <lordievader> hariom: Have you checked nmap already?
[18:34] <hariom> lordievader: http://pastebin.com/a5Hzsswk
[18:35] <lordievader> hariom: Your pc sees an open port 80.
[18:35] <hariom> lordievader: What do you suggest ?
[18:36] <hariom> How to fix this. I don't have firewall enabled. And all outgoing are allowed
[18:36] <lordievader> hariom: Try to connect to it with netcat, see what happens.
[18:39] <hariom> lordievader: I don't see any output from "nc <IP_ADDRESS> 80"
[18:40] <lordievader> hariom: Type something and hit enter a bunch of times.
[18:41] <hariom> lordievader: http://pastebin.com/9t2knt5i
[18:44] <lordievader> As I figured, you have no connection problems with the server.
[18:46] <hariom> lordievader: I have simply typed that ip on brower and got apache page so means port 80 was fine.
[18:48] <hariom> lordievader: any idea why there is error in fetching packages
[18:49] <lordievader> hariom: You where performing those tests from the client with the connection problems right?
[18:50] <hariom> lordievader: I am upgrading 12.04 on remote server from my laptop
[18:50] <hariom> I am able to connect and perform actions on remote server. No issues in that
[18:50] <lordievader> hariom: Is that a yes, or a no?
[18:50] <hariom> no
[18:51] <hariom> I had no connection problem between client and server. Server is fetching these repo
[18:53] <coreycb> zul, can you review?  https://code.launchpad.net/~corey.bryant/horizon/2014.2.1-2/+merge/244199
[18:53] <Vladimirov> Trying to change shell from /bin/sh to /bin/bash for a user with chsh but nothing happens, it changes to /bin/bash/ but the shell is still the same:/
[18:53] <Vladimirov> i did it before on another server and it was all goodie but not on this one..
[18:54] <coreycb> zul, hmm, I might need the sru bug # included in that
[18:55] <zul> coreycb: it doesnt apply to 2012.2.1
[18:55] <coreycb> zul, yeah, ok
[18:56] <lordievader> hariom: Err what point does it make to test these things on a computer that does not have the problem?
[18:58] <hariom> lordievader: didn't get what you mean
[18:58] <hariom> I want to upgrade from 12.04 to 14.04
[18:58] <hariom> Server is located far away
[18:59] <hariom> Following: http://ubuntuserverguide.com/2014/06/how-to-upgrade-ubuntu-server-12-04-to-ubuntu-server-14-04-lts.html
[19:00] <lordievader> hariom: You have a connection problem on your server (I think), I give you instructions on how to figure out what is causing these connection issues. You perform these instructions on a different pc (I think) that doesn't have the problem. <- this defeats the entire purpose of those tests.
[19:02] <hariom> lordievader: nmap and nc were ran on the same server
[19:02] <sarnold> hariom: then perhaps it was a transient failure? retry?
[19:03] <hariom> sarnold: Already tried with 4 times. Changed mirros as well. Restarted remote server but nothing seems to work. and if you type that ip in browser, it is just an apache default page
[19:03] <lordievader> hariom: Hmm, now I'm confused.
[19:04] <sarnold> hariom: sure, that's sometimes how namebased virtual hosting sometimes works
[19:04] <sarnold> if you load e.g. http://in.archive.ubuntu.com/ubuntu/ you'll see it actually has the pool/ and dists/ as expected
[19:05] <hariom> sarnold: I am able to update. I did dist-upgrade and it went fine
[19:06] <hariom> sarnold: why it says Connection failed [IP: <IP_ADDRESS> 80]
[19:07] <sarnold> hariom: dunno, I'm surprised it didn't include a more specific error that might help you troubleshoot the problem
[19:09] <sarnold> hariom: normally, I'd expect something like that to come from firewalling between your host and the remote host; whether it's on the server or one of the routers between
[19:09] <sarnold> hariom: try tcptraceroute to the IP, see what happens
[19:10] <sarnold> hariom: if it keeps happening, maybe try a different mirror, mirror.anl.gov is my favorite -- wrong continent, perhaps, but it has serious bandwidth, and might be able to out-do a local mirror anyway
[19:13] <hariom> sarnold: ok
[19:18] <hariom> sarnold: ok, I tried again. It went upto 92% completion but then again showing failed to connect
[19:19] <sarnold> hariom: interesting... do you have a rate-limited connection or something similar? o_O
[19:21] <hariom> sarnold: no
[19:23] <lucid_interval> I have a HP All-In-One network scanner that has been and is detected and configured using hplip (hp-setup). I want to share this scanner to other Linux clients using saned. I had a perfectly working setup on Precise 12.04. After upgrade to trusty, client connects (entries in /var/log/saned.log) but scanimage -l on client does not show any scanners.
[19:24] <lucid_interval> Also tried adding localhost and <IP_ADDRESS> to /etc/sane.d/saned.conf and /etc/sane.d/net.conf on the server and server can't see scanner either through net backend (any more)
[19:24] <lucid_interval> Any clues on what has changed in saned between precise and trusty?
[19:25] <lucid_interval> scanimage -L on the server DOES detect the scanner - through the hpaio backend, but not through the net back end
[20:19] <DenBeiren> lordievader: you there?
[20:27] <lordievader> DenBeiren: Half, what is up?
[20:28] <DenBeiren> i got my samba issue working (if you remember)
[20:28] <DenBeiren> added inherit permissions = yes
[20:28] <DenBeiren> and chmodded all to 2770
[20:31] <lordievader> DenBeiren: That is good to hear :)
[20:32] <DenBeiren> wanted to say thanks to help me out :-)
[20:32] <DenBeiren> i do have a new problem tough :s
[20:33] <DenBeiren> http://pastie.org/9770644
[20:34] <sarnold> DenBeiren: ltrace that, it should give you a good hint where it was when it died
[20:35] <DenBeiren> sorry sarnold i'm afraid i don't know what you want me to do (nog a linux guru i'm afraid)
[20:36] <sarnold> DenBeiren: ah :)  run "ltrace -o /tmp/testparm.out testparm"  -- then read through /tmp/testparm.out, it'll include a lot of library calls and so forth, and hopefully it'll include the strings it read from the configuration files moments before it declares failure
[20:36] <sarnold> DenBeiren: scroll right to the end of the /tmp/testparm.out and start reading backwards
[20:37] <DenBeiren> http://pastie.org/9770655
[20:39] <sarnold> DenBeiren: yikes :)
[20:39] <DenBeiren> strange things huh
[20:39] <sarnold> DenBeiren: that's way less helpful than I expected. sorry.
[20:39] <DenBeiren> lol
[21:54] <lvmer> Anyone remember how to change the default duration for pastebinit?  I remember each website listed in the config having it's own options file, but cannot seem to find them
[22:44] <MrPPS> Is it just me, or are apparmor-utils stil broken in 14.04?
[22:51] <mdeslaur> MrPPS: still broken, we'll have an update soon
[22:51] <MrPPS> ah, cool :) I just saw some launchpad stuff from a couple months ago which mentioned it'd be updated
[22:51] <MrPPS> just checking I hadn't somehow missed that update
[22:51] <MrPPS> cheers!
[22:52] <mdeslaur> MrPPS: yeah, sorry about that, it's taking longer than we hoped
[22:52] <MrPPS> all good :) I imagine these sort of things are fairly complex, so I'm in no place to judge :D
[22:52] <MrPPS> what sort of issues are you encountering, if I'm allowed to ask?
[22:53] <mdeslaur> every time we were about to release an SRU to trusty, we'd get more fixes, so we'd defer
[22:53] <mdeslaur> the tools are all new code, and we knew there would be issues, just not this many
[22:53] <mdeslaur> but the good news is things have stabilized now, so we should be able to push an update soon.
[22:54] <MrPPS> nice :) well, I'm looking forward to it
[22:54] <MrPPS> to be honest, I've not mucked around with apparmor much; just started looking at it last night
[22:54] <MrPPS> went to start the profile creation, and that's where I encountered that issue
[22:54] <MrPPS> so I'm looking forward to playing around with it in the near future
[22:55] <MrPPS> thanks for your work on it, whatever your role! :)
[22:56] <mdeslaur> you're welcome
[22:57] <jjohansen> MrPPS: if you are so inclined there is a backport PPA for the utopic version of the apparmor tools, it has many of the fixes in it
[22:57] <patdk-wk> what does the util do?
[22:57] <patdk-wk> atleast, I hadn't noticed an issue
[22:58] <jjohansen> MrPPS: https://launchpad.net/~apparmor-dev/+archive/ubuntu/apparmor-backports
[22:58] <patdk-wk> ah, I don't even use apparmor-utils, not installed
[22:59] <patdk-wk> but apparmor works just fine :)
[22:59] <jjohansen> patdk-wk: the apparmor-utils are tools used for developing profiles
[22:59] <patdk-wk> ya, I normally just write the profiles myself by hand
[22:59]  * patdk-wk notes, vi works well :)
[22:59] <MrPPS> I'll take a look; thanks jjohansen
[22:59] <patdk-wk> likely why I didn't notice
[23:00] <jjohansen> patdk-wk: right apparmor should be working fine, its the utils that underwent a major rewrite, it started out as a Google summer of code project
[23:00] <MrPPS> yeah; having not mucked around with it before, I wanted to generate a few profiles so I can see how it looks/works
[23:00] <patdk-wk> ya, my usage was too broad, to use a profiler on, to generate the rules for me
[23:02] <jjohansen> patdk-wk: the tools aren't automatic, they just help. They scan the logs, and ask you if you want to add a rule to the profile etc. I think if you know what you're doing manually authoring the profile is more flexible
[23:02] <jjohansen> but for those that just want to get rid of a couple of denied messages, they work okay
[23:02] <patdk-wk> yep
[23:47] <NTQ> Hi. I need some help configuring Dovecot and Postfix. I can send mails to a virtual user, but I can not login as that user to get the mails. Here is my configuration: http://nopaste.info/fda2a674bb.html
[23:48] <NTQ> patdk-wk: I started from beginning and using an up-to-date tutorial in contrast to yesterday. ;)
[23:49] <NTQ> Maybe the password encryption is wrong or something like that. But I don't know how to debug this.


[12:01] <cjwatson> soren: blame ext4's requirement to use fsync in order to get safe atomic rename (it's hard to tell whether the filesystem needs this, so dpkg needs to be conservative)
[14:01] <ev> I thought XFS was agreed to be a Very Bad Thing(tm), no?  The kernel guys were loudly complaining about it the other day.
[14:05]  * soren has sworn by xfs for at least half a decade. admittedly, yesterday I mostly swore at or about it instead.
[14:10] <ev> heh
[14:10] <ev> fair enough
[14:11] <ev> I'm just content to fanboy the unicorns promised by btrfs