User1: I'm having difficulty connecting to my printer.  I set up a USB connected printer attached to my print server using CUPS.  From my desktop,  I let it find the printer connected to the server (Server and Desktop are on the same LAN).  I can print a test page from CUPS connected to the server (192.168.0.xx:631, but I cannot print a test page from CUPS connected to my desktop (localhost:631).  Ideas?
User2: check cups logs on both systems?
User1: Sarnold:  got it working.  Thaks
User2: User1 nice, what was it?
User3: Hey guys, I am in a situation hopefully you can help me. So for some reason I decided to make my boot partition 400gb. I am wanting to move that 400gb of free space from sda1 to sda6, is there a way for me to do that? or what would I have to do.
User4: hello all
User5: win 6
User6: Good morning.
User7: User12 I'm going to release security updates for mysql, can you confirm that the packages in -proposed are all tested?
User7: User12 also, since we always ship the latest upstream mysql, I'm not sure how we're supposed to maintain those patches...have they been submitted upstream?
User8: They are proposed and not yet finally tested. If they are tested fully. They are moved out of proposed.
User9: hi there
User9: need help for ubuntu server
User9: our Raid1 sytem failed to start after a power loose in our place
User9: anybody here?
User10: !patience
User11: Don't feel ignored and repeat your question quickly; if nobody knows your answer, nobody will answer you. While you wait, try searching https://help.ubuntu.com or http://ubuntuforums.org or http://askubuntu.com/
User9: no boot paste.ubuntu.com
User10: You might want to state your actual problem though. Volunteers tend not to want to commit to helping someone with open ended problems because they tend to take an open ended amount of time.
User9: no boot http://paste.ubuntu.com/11887633/
User9: softraid
User6: User9 Did you boot a live stick, is your data still there?
User9: i will boot via live stick in few minutes
User9: still downloading one
User9: the question is what is the best way to make the raid work again
User9: seems to me that the bootloader didn^t load the raid partition
User6: First see if the data is still there. See what the damage is.
User12: User7 the only thing that still needs testing is the trusty update, which FTBFS due to an unrelated issue. there's a fix for that in the sru queue.
User12: User7 oracle is looking at fixing it - they can't take my fix because it's a port from mariadb that wasn't contributed under the OCA (noted in the dep3)
User12: User7 trusty mysql-5.5 is good, mysql-5.6 is the one in the SRU queue
User7: User12 all I care about is mysql-5.5/trusty, mysql-5.5/utopic and mysql-5.6/vivid
User7: User12 are those tested?
User12: User7 yes they are
User10: o/
User10: User12 http://paste.ubuntu.com/11887850/ to catch up from #ubuntu-hardened
User10: (sorry I didn't notice this concurrent conversation)
User7: User12 so I wasn't part of the original discussion with regards to those patches...I added my concerns to the bug
User7: but rbasak has now told me it's been discussed
User7: User12 so my understanding is that if I prepare a new mysql version and the patches don't apply I just ignore them?
User12: User7 that would cause memory corruption for ppc64el/arm64 users
User7: of course, that is likely to regress users who think mysql is usable in trusty
User12: so i don't think ignoring them is a good approach
User7: User12 right, so are you commiting to getting me updated and tested patches for each new mysql release as soon as it comes out?
User10: My understanding was that if dannf's team can't fix it, then we wouldn't hold up a security update for the other archs.
User7: I can't selectively publish archs
User7: unless it FTBFS
User10: Right, so that would mean regressing arm64 etc.
User7: rbasak, User12 if the patches do appear to apply, and it builds, do I release the new version without testing on ppc64el and arm64?
User10: I'd say yes.
User12: User7 to the extent reasonable, yes (i commit to updating), but that does need some time
User10: Again, I apologise for not speaking to you before. I don't want to see this as a done thing - if that doesn't work for you, we should speak and reconsider.
User12: mdeslaur, rbasak +1 - if it applies, go for it
 * dannf understands this is a bad situation - wish i could do more, but nothing i can personally do since i don't hold copyright on the fix
User12: but i can poke oracle again and ask about status
User10: I wonder if we should reconsider Oracle MySQL's place in main on the basis of this issue.
User10: On one hand the patch author won't sign Oracle's agreement, but on the other hand it's Oracle that won't take the patch and haven't fixed the bug.
User10: Combined with them not providing security patches.
User7: User10 while that's a good discussion for the dev release, it doesn't change anything with regards to the stable releases that I have to update in the next couple of days
User10: User7 understood. If you're still unhappy, I think we should reconsider carrying the patch.
User7: adding these patches to trusty means every three months for the next 4 years the patches need to get rebased and tested on the latest mysql version
User12: User7 until oracle releases an update with a proper fix, yeah - which they are working on
User7: right
User7: ok, so here's the plan: 1- rbasak please find someone in the sru team to release the packages currently in -proposed ( mysql-5.5/trusty, mysql-5.5/utopic and mysql-5.6/vivid)
User7: either today or tomorrow
User7: that way, those will be available for ppc64el nd arm64
User7: I will prepare updates for the new versions with the patches
User7: If they apply, fine, if they don't, I'll ping dannf
User7: I may publish the updates anyway, just not for the two archs that FTBFS
User12: User7 can you point me at the new release/patches/whatever, so i can look at the risk ahead of time?
User7: depending if dannf can quickly get me updated patches
User7: User12 that would be the 5.5.44 and 5.6.25 new upstream versions from mysql's site
User12: User10 arges approved the srus, i can ask if he'll flush -proposed for us
User10: OK. I'd like to delegate chasing the SRU team to dannf, if dannf you're OK with that.
User10: Though, this assumes that mdeslaur you're happy with this situation.
User10: If you're not and think we should reconsider carrying the patches in the first place, then we should do that before releasing the SRUs.
User7: well, I can't say I'm happy with the situation...this definitely makes things more complicated, and has a chance of regression users of those archs
User7: but if those archs are broken anyway...
User7: if dannf and/or his team are willing to drop everything when a security notice is published to get the patches working for a new version within a day or two, then that's fine
User10: I take the view that the patches can't be allowed to hold up security updates for the other architectures, and nor can we expect mdeslaur's team to fix it.
User10: So that means dannf's team gets the opportunity to fix it when necessary, or if not, then the affected architectures regress.
User12: i can't commit anyone else from my team - but, unless i'm unreachable, i can commit myself to that
User13: hey guys, I have a service i'm making that can have multiple instances running on the same box. how should i represent that in systemd?
User10: User13 http://0pointer.de/blog/projects/instances.html
User13: User10 wow thanks
User13: that was fast
User13: User10 I hope this wasn't the first google result ;-P
User10: User13 https://encrypted.google.com/search?hl=en&q=systemd%20multiple%20units
User13: haha
User10: But you do need to know what terms to Google for :)
User7: rbasak, User12 ok, so we're on the same page?
User13: i didn't think "instance" was the right word
User12: it would be nice if we had a way to at least not release broken builds on those archs in the situation that we can't. i'd hate to knowingly release broken builds to someone's stable environment
User13: User10 instance brings up the same first result /me is embarrassed
User13: ty
User10: User12 I suppose the patches could FTBFS and then users will be held back on that arch. But we'd need to check what the Arch: all packages do in terms of versioned dependencies.
User7: User12 is there a quilt trick to get it to apply the arch specific patches to see?
User7: User10 oh, argh, I didn't think about the Arch: all
User10: User12 but that also means that affected arches will never get a security update. So which is worse?
User12: User7 ln -s debian/patches/arch-specific/patches-arm64 patches-amd64
User12: User10 tough to say in general - one is definitely going to break them though, the other (security) is status quo
User12: but security could certainly be worse in some situations of course
User12: and w/ mysql, we don't really know what the security issues are :(
User10: Maybe the fact that we're considering this should mean that we shouldn't carry the patch and consider MySQL broken on the affected arches until an upstream fix arrives.
User10: I'm seriously reconsidering my position here.
User12: User10 that feels like we're saying x86 is more supported than other archs, which isn't what we communicate
User7: it's quite unfortunate that this is with the mysql package...pretty much any other package in the archive where we can backport security fixes this wouldn't have been an issue
User12: if there was corruption in an LTS main package on x86, wouldn't we carry a patch?
User10: User12 I feel like we're saying that in the case of Oracle MySQL, upstream policies mean that for us to keep it in main arches are supported only as well as upstream support them.
User10: User12 for src:mysql-*, I'm not sure, because of upstream policies it's a special case.
User10: It only remains in main because upstream has a good track record on this (until now).
User10: http://www.ubuntu.com/about/about-ubuntu/conduct - "We expect participants in the project to resolve disagreements constructively. When they cannot, we escalate the matter to structures with designated leaders to arbitrate and provide clarity and direction."
User10: I'm tempted to say that we're getting to the point where we need a TB decision in order to be decisive.
 * dannf feels like we have a working model (dannf will port) and a backup plan (will drop patches) - i don't see why dropping those patches would be better, unless there's no reasonable grace period to give me to port
User12: counter argument is that right now we don't have working packages on those archs - but i don't know that that is obvious to any users. the builds are there.
User12: they will just secretly eat your data
User7: right, that is why I'm conflicted
User10: 1) I don't like the bus factor in that. I feel that we should have a team commitment to port the patches.
User10: 2) Falling back to the backup plan means regressing users, who might elect to use an alternative if they know in advance, rather than receiving a regression. So the existence (and need for) the backup plan gives me doubt. Are the chances of needing it great enough that we shouldn't consider builds on these arches to be usable?
User12: i'm sure we can get others on my team to commit to the raw porting - my only concern is w/ the actual packaging
User7: User12 ideally someone on your team would maintain a tested PPA for each new upstream version of mysql with the patches applied, and tested
User12: and i should be open to my potential conflict of interest - i'm paid to support arm64 customers who want to deploy this
User7: so when oracle's quarterly security advisory goes out, I can pluck the updated patches out of the PPA
User12: User7 that seems reasonable
User10: Aren't a significant proportion of upstream releases from security advisories (ie. not available earlier)?
User7: seems to me they come out earlier than the security advisories
User7: I'm trying to find that out now
User10: Even though we had the MRE approved, I've not had the time to keep up to date with new upstream releases.
User7: 5.5.44 came out on 2015-05-29
User7: and they published the security advisory for it this week
User12: is there an announce list for new releases?
User10: Ah, so they release first and then tell people what security fixes (if any) were in it six weeks later? I didn't realise that.
User10: If that's true then it seems to me that if we did keep up with the MREs then you'd just need to pocket copy to -security
User7: I'd have to rebuild in -security
User10: Ah, OK
User10: So...does this mean that dannf's team will do the MREs for us? :)
User7: heh
User7: IT'S A TRAP!
User7: ;)
User10: :)
User10: It does seem like the logical conclusion though!
User7: User12 sorry for making this seem complicated, but this sort of thing has happened before...and while everyone has good intentions, at some point down the road when code gets refactored, nobody has time to do the work anymore
User7: and that's when we're stuck with the hard decision
User7: so I just want to make sure we're on the same page if it comes to that and we do need to regress our users
User12: User7 right, part of our agreement here was to make sure we had a long term plan - i.e., oracle will care/provide a fix. we have that commitment, but no ETA
User7: oh, that's good news
User12: we've got them hw to test with, etc - we're poking them about status today
User7: ok, I wasn't aware that there was a commitment there...that definitely alleviates my concern a bit to know that these could possibly be upstream in the next few versions
User12: as for us doing MREs - i don't think that's necessarily a bad idea for this period. of course, if builds/tests fail for unrelated reasons, that's something we'd need help with
User12: though i'm still not sure on how to get informed about a new release
User10: I'd expect my team to help with anything MRE related, though priority would be up to my manager.
User10: (and thus time)
User7: ok, so the patches do apply to the new 5.5 and 5.6
User10: As for being informed about a new release, I don't really know either.
User10: Perhaps we should set something up to watch uscan.
User10: That'd be useful for other packages too.
User7: yeah, or script something to monitor dev.mysql.com
User7: perhaps there's a mailing list, I'm not sure
User12: i can ask oracle
User12: User10 User7 at this point, are you both ok w/ me asking sru-team to push those updates out?
User10: User12 I wonder if it's an idea to write out what we've agreed first to make sure that everyone is in agreement?
User7: yeah, adding a comment to the bug to state what we've agreed would be ideal
User7: once we've stated it here
User10: Maybe start in a pad to avoid confusing updates in the bug.
User7: right
User12: sure. 1) dannf's team will figure out how to be notified of micro releases and maintain a ppa of test builds that we use to validate on arm64
User12: oh, pad is fine
User7: User10 do you have a pad?
User10: mdeslaur, User12 http://pad.ubuntu.com/mysql-arm64-corruption-patch
User10: (I just created it)
 * rbasak wonders why everyone is a shade of pink today
User12: btw, i'll run this by my manager this morning to make sure we can deal w/ the bus factor
User12: mdeslaur, rbasak and are these updates always quarterly?
User7: User12 the security notices are quarterly
User7: User12 the mysql updates happen at any time I believe
User7: ie: there can be 2 updates between security notices
User12: ok
User7: so you can plan when you're going to update your PPA, as long as it's done before the security notice is published, which is usually at a pre-determined date
User7: does that make sense?
User12: User7 yes. is there a security notice list, or should i ask oracle about that too?
User7: User12 http://www.oracle.com/technetwork/topics/security/alerts-086861.html
User7: the dates, and the notices are listed there
User7: no next date is 20 October 2015
User10: So arm64/ppc64el users are at some risk of regression as it's not an upstream patch. Should we release note this?
User10: (although of course it's going into Trusty too, for which release notes are already published)
User7: User12 so _if_ a new version is published at the same time as the security notice (I don't think that happens), is a 2 day delay enough?
User7: User10 hrm, is changelog not enough?
User7: User10 not sure where else to put it
User10: User7 changelog will have to do I guess. My thought is to inform users of the risk _before_ it happens.
User10: (as it might affect DB or platform choice)
User7: User10 if we do have to drop the patches, we can add a notice to the USN text
User10: That would certainly be useful.
User12: User7 i suspect a 2 *working day* delay would be enough
User7: User10 ok, added to pad
User7: User12 ah, right, that's what I meant, I'll clarify
User7: I'm satisfied, are you rbasak, dannf?
User12: +1
User10: +1
User7: awesome
User7: I'll add the info to the bug
User14: I'm sorry I was in a meeting
User7: User12 is the mention of your commitment from oracle in the pad an issue?
User12: User7 let me confirm w/ my manager first, if that's ok - should be within this hour
User14: can someone tell me why the patches aren't upstreamable? certainly, upstream would want these to work well on those archs?
User14: (speaking of mysql)
User7: User12 yes, definitely
User10: User14 the patch author declines to sign Oracle's agreement.
User14: who is the patch author?
User12: User14 mariadb devs
User14: meh
User7: User14 it's a licensing issue, but dannf's team does have a commitment from Oracle to fix the issue themselves
User14: is there an upstream bug with mysql so they can clean room patch it?
User14: ok
User7: User14 yes, there's a bug
User10: http://bugs.mysql.com/bug.php?id=76135
User14: so this situation is 'temporary'
User12: User14 yes, and they have engaged - but i don't know the status, we're asking today
User14: alright, whatever you've come up with between you and mdeslaur is fine with me
User7: User14 are you ok with what's in the pad?
User14: I just wasn't clear on that point
User14: can you paste the link?
User7: User14 http://pad.ubuntu.com/mysql-arm64-corruption-patch
User10: http://pad.ubuntu.com/mysql-arm64-corruption-patch
User7: http://pad.ubuntu.com/mysql-arm64-corruption-patch
 * jdstrand reads
User10: Did you get that?
User10: It's http://pad.ubuntu.com/mysql-arm64-corruption-patch :-P
User7: hehe
User14: wait, what was the link?
User14: :P
User10: User14 http://pad.ubuntu.com/mysql-arm64-corruption-patch :-P
User7: User14 http://pad.ubuntu.com/mysql-arm64-corruption-patch
User14: ah, right. thanks! :)
User7: hehe
User7: nerd humour
User14: do we have an idea of when Oracle will fix it? eg, is there a reasonable expectation that it will be fixed for next quarter's update?
User14: I agree with the agreement :)
User14: please put it in the sru bug so they are aware too
User7: User14 yes, that is the intention, as soon as dannf's manager signs off on it
User14: great
User15: User10 incoming PM, unrelated
User12: mdeslaur, rbasak, jdstrand : andrewc added some CYA text to the top, but otherwise approves. can we retroactively add this to the trusty release notes?
 * rbasak scrolls back to find the link
User10: User12 you might need to s/we/ with something to make it clear.
User10: I don't know whether retroactively changing the release notes is a thing
User10: There are point release release notes though
User10: Maybe a question for the release team.
User12: ok
User10: I think it does make sense to alert users to the issue through the release notes in principle
User12: so maybe just queue it up for the next point release if it hasn't been fixed properly by then
User10: I'll ask in #ubuntu-release
User10: User16 FYI https://lists.ubuntu.com/archives/technical-board/2015-July/002125.html thanks to teward
User16: git comm\o/
User16: whoops, I mean, yay! \o/
User15: lol
User15: User16 copy-paste fail? :P
User16: indeed
User16: more like window focus fail
User16: we really need a focus-follows-eyes window manager
User15: :P
User15: or direct neural communication with systems
User15: in any case this is up at the TB now, so we can only hope at this point :P
User10: Don't worry, the TB are on our side. They want Ubuntu to continue to be awesome too :-)
User7: User12 cool, can I paste that into the SRU bug?
User12: User7 yeah
User7: thanks dannf, rbasak!
User12: User10 btw, is there an existing PPA/group that makes sense for these pre-release builds, or should i just shove one under ~ce-hyperscale?
User10: User12 there's https://launchpad.net/~mysql-ubuntu
User10: User12 however that isn't Canonical only, so I don't think we can get a devirt PPA there.
User10: I'm not sure of the current status of virt/scalingstack builders for arm64 and ppc64el. Might be worth enquiring.
User17: Hi all, newbie here, simple question. I access my server via ssh. When I first started I did the manual username/password and I would always get the default MOTD. Now I login by key authentication and no more MOTD. I even went into sshd_config and changed PrintMOTD to 'yes'. It prints last login but not MOTD. What gives?
User17: As a side note I've been doing key based login for a while now and I just happened to notice that I miss the motd.
User18: User17 https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/543767
User11: Launchpad bug 543767 in openssh (Ubuntu) "ssh logins doesn't show the MOTD when connecting with public key authorisation" [Low,Expired]
User17: Oh okay well at least I know it's a bug. Why is it expired? Can it be reported again?
User17: I'm reading...
User18: User17 just add a comment of your own. it doesn't seem right to me. i presume you are running 14.04?
User18: User17 as a workaround you can always call motd from your init shell files. the bug mentions how
User17: Yes 14.04. I think I found the problem, about to test...
User17: Okay so
User17: I had to set UsePAM to yes in sshd_config and now it prints the motd
User17: Apparently the motd is generated with PAM
User17: These guys say that as long as challenge response authentication and password authentication are set to no and public key authentication is set to yes then it's fine
User17: Thanks guys!
User18: User17 ok, i read it too quickly then
User19: I'm using an internal mirror of Ubuntu 14.04 (amd64 architecture only), and I'm finding that I have to run "dpkg --remove-architecture i386" in order for things to work on 64-bit installs of Trusty. Is this expected? If so, is there a setting/way to automate this?
User19: patdk-wk: Can you elaborate on the required 32-bit packages?
User19: patdk-wk: Let's assume that I'll only be using 64-bit software (these are stripped down server builds). Does that change the picture?
User19: patdk-wk: Or is that assumption flawed? In other words, is it not possible to use only 64-bit software/packages on a typical Ubuntu Server build?
User19: patdk-wk: When I run "dpkg --print-foreign-architectures" on the server(s), the result is empty (meaning only 64-bit packages are installed).
User19: patdk-wk: However, when I try to use the amd64-only internal mirror, it will fail until I run "dpkg --remove-architecture i386". This is even though "dpkg --print-architecture" returns *only* "amd64".
User15: patdk-wk: it's in the manpage
User19: patdk-wk: This is 14.04.2
User19: patdk-wk: No worries :-)
User15: patdk-wk: https://pbin.dark-net.net/view/raw/3d72be32 <--- just for the future :)
User19: patdk-wk: That's what I just got, but I'd already run it once, so I'm guessing the command isn't idempotent and tries to do something again.
User19: patdk-wk: In any case, do you know of any file/setting that is modified by that command that I could track? This would allow me to use Ansible to run that command and then track if the command has been run before.
User19: patdk-wk: I'm using a plain jane Vagrant box I built myself using a standard Ubuntu Server 14.04 installation. I'll dig in a bit more---thanks for your help.
User20: User19 you can answer this yourself by running strace and seeing which files dpkg --remove-architecture i386 removes.
User20: User19 I used to rm -f /etc/dpkg/dpkg.cfg.d/multiarch to do the same thing.
User19: jrwen: Thanks, I'll give strace a go. /etc/dpkg/dpkg.cfg.d/multiarch doesn't exist on these systems, though.
User20: User19 did you already run dpkg --remove-arch... on those systems?
User19: jrwen: Nope. This is on a fresh instance of a Ubuntu 14.04 Vagrant box, and "dpkg --print-foreign-architectures" does report "i386".
User20: User19 Ok, thanks.
User19: jrwen: However, I see a package called "multiarch-support"...going to try removing that to see if that does anything. (This is a Vagrant box, so no big deal if it blows up.)
User19: User20 That won't work. Wants to remove most of the packages on the system. :-)
User19: Found it...dpkg architectures are stored in /var/lib/dpkg/arch, each architecture on a separate line.
User19: Removing "i386" from that line fixes the original issue AFAICT (internal amd64-only mirror works as expected with no errors). Now to automate this with Ansible...
User20: slowe[away]: works for me. I do it very often.
User20: slowe[away]: why the desire to remove foreign arch?
User21: Anyone here ever seen /dev/sda as "hp ilo internal sd-card".  I can't get kickstart to install lvm correctly because it always wants to install it there even when I tell it to install it to /dev/sdb which is my hdd.
User8: Yes, almost every of our servers behaves like that.
User21: what's your workaround?
User8: Either pull the sd card, or install to the /dev/cciss/ raid controller logical volumes you created before.
User21: that's nto exactly what I wanted to hear, but I appreciate the help.  Looks like a trip to the datacenter tomorrow.
User8: I assume you have no raid controller then?
User21: I'm not really sure how to point it to /dev/cciss/.  Should I define that in the kickstart file?
User21: I'm doing a network install now without any automation.  In the beginning I did a rmmod usb_storage and when it came to the partition section, it didn't see it.  I'm going to try to incorporate that into the automated kickstart file.
User19: User20 Sorry, had to step out for a bit. Need to remove foreign arch because internal amd64-only mirror won't work otherwise (apt-get reports can't find binary-i386 packages).
User2: User19 did you try prefixing your apt entries with e.g. deb [arch=amd64] http://....  ?
User19: User2 In sources.list?
User2: User19 yeah
User2: https://wiki.debian.org/Multiarch/HOWTO
User19: User2 No, hadn't tried that. Will give that a try! Is there a strong advantage one way or the other?
User8: User21 First, make sure you have the required hardware :)
User21: I do
User8: Then remember to create a logical volume on your raid controller before installing an OS.
User8: Or automate it, using kickstart and an external script.
User2: User19 heh, no, this was the easier way I found for dealing with a similar problem
User19: User2 Fair enough :-)
User2: User19 though perhaps it's nice i fyou've got multiple deb sources, and one of them is e.g. amd64 only, but your system still needs the 32 bit stuff from other mirrors
User19: User2 Sure, that makes sense
User13: anyone know how to start a systemd user service as a non-root user?
User15: anyone ever hear of a server randomly stop logging to syslog?
User15: or dmesg
User22: User15 I have not
User15: User22 nor have I, it's new to me to see that
User15: meh, not super important since all that's there is bind9
User2: or a race condition between the log rotation and the logging system closing and opening the new file -- see if the logs are going to the .0 or .1 file instead
User2: yeah, dmesg should always work, but the benefit there is only the kernel gets to write to it :)
User15: patdk-lap: no dmesg either, which is REALLY odd
User15: and i rebooted the server just in case
User15: so maybe it's a perms problem
User15: no output
User15: nor did /var/log/dmesg have anything
User15: which was really od
User15: odd*
User15: would the `dmesg` command still output?
User15: and if it doesn't
User15: should i drop a nuke on the server?
User15: wouldn't put it past this VPS image
User15: but it was doing those before
User15: openvz but yes
User15: heh
User15: i know syslog was working though
User15: because bind9 would report there
User15: mhm
User15: i'm not horribly worried about it, i could tell bind9 to log to a file instead of syslog but i'm lazy
User2: openvz may force kernel.dmesg_restrict=1 in their containers..
User15: User2 quite possible.  i'm looking to put bind9 to a file rather than syslog where i can, now, since that's really the only log I care about
ubuntu-server
Ubuntu IRC