[00:52] <Iskorptix_> hi, whats the default version of perl in latest ubuntu server ?
[00:53] <ironhalik_> Hello
[00:53] <bigjools> https://launchpad.net/ubuntu/+source/perl
[00:53] <ironhalik_> I am using Ubuntu Server 12.04, and the notification about updates, when you login via ssh, seems to be missing
[00:54] <Iskorptix_> bigjools thanks
[00:54] <sarnold> is pam_motd.so still in your /etc/pam.d/* configs?
[00:55] <ironhalik_> sarnold: nope
[00:56] <sarnold> ironhalik_: in my /etc/pam.d/sshd:
[00:56] <sarnold> # Print the message of the day upon successful login.
[00:56] <sarnold> session    optional     pam_motd.so # [1]
[00:56] <sarnold> (yes, even with # [1] -- no idea what that refers to)
[00:57] <ironhalik_> hmm, isn't it provided by landscape?
[00:57] <ScottK> No
[00:58] <ironhalik_> I remeber landscape having something to do with the motd displaying packages that needed updating
[01:03] <sarnold> landscape provides a similar buyt different display
[01:05] <patdk-lap> ironhalik_, you mean, /usr/lib/update-notifier/update-motd-updates-available
[01:05] <patdk-lap> defently not part of landscape
[01:06] <ironhalik_> ah, then I was thinking about the load, etc info
[01:06] <patdk-lap> ironhalik_,  /usr/lib/update-notifier/update-motd-cpu-checker
[01:06] <patdk-lap> oh opps, not that one :)
[01:06] <ironhalik_> patdk-lap: either way, the info about new packages is not showing
[01:07] <patdk-lap> well, then your missing update-notifier
[01:07] <patdk-lap> or update-motd
[01:07] <ironhalik_> nah, I've got update-motd
[01:08] <ironhalik_> does update-notifier really requires 193 packages :>
[01:08] <ironhalik_> ?
[01:08] <patdk-lap> if you install the gui one
[01:09] <ironhalik_> Hmm, dunno - I tried out ubuntu server on a VM, it had a nice update notification
[01:09] <ironhalik_> (the default image from ubuntu.com)
[01:09] <ironhalik_> on my VPS, its lacking it
[01:11] <patdk-lap> I always use minimal/jeos install, so I never have it
[01:11] <ironhalik_> I kinda liked it :)
[01:11] <patdk-lap> likely you just need update-motd and update-notifier-common
[01:12] <ironhalik_> ah, finally!
[01:12] <ironhalik_> had update-motd, needed update-notifier-common
[01:12] <ironhalik_> thanks guys!
[02:13] <Iskorptix_> hi, how I can enable root login over ssh ? PermitRootLogin yes is not enough in sshd config
[02:14] <Iskorptix_> I know I shouldn't be doing that, but I need it to be enabled
[02:14] <qman__> it is enabled by default, but root doesn't have a password by default
[02:14] <qman__> to log in as root over SSH, use SSH keys
[02:15] <qman__> you should not under any circumstance allow root login with a password, that's just asking for a bot to break in
[02:19] <sarnold> qman__++
[02:20] <qman__> I usually turn off root login altogether as a failsafe, but using good keys and keeping those keys secured is reasonably safe
[02:21] <qman__> allowing password authentication, no matter how good your passwords are, is not very safe at all
[02:21] <qman__> because it only takes one mistake to accidentally set that password to something weak or to leak it out somehow
[02:22] <qman__> and it's a one-factor attack, the username is known
[02:22] <qman__> if you prevent root from logging in, you've increased the difficulty
[02:22] <qman__> because the attacker has to know your user name too
[02:22] <qman__> admittedly not the most secure information, but an unknown is an unknown
[02:25] <Iskorptix_> qman__ agree, but machine is not visible to the internet, so its safe
[02:26] <Iskorptix_> anway, thanks
[02:26] <qman__> it's still bad practice and you shouldn't do it
[02:26] <qman__> even if it isn't now, it could be later, or it could be reachable and you just don't know it
[02:26] <Iskorptix_> well, I used to think like that, but recently come to conclusion, that machines should make life easier, not harder
[02:26] <qman__> keys are easier than passwords
[02:26] <Iskorptix_> sometimes its good to use passwords
[02:27] <sarnold> keys are _way_ easier than passwords
[02:27] <sarnold> faster
[02:28] <sarnold> more reliable
[02:28] <sarnold> safer
[02:28] <sarnold> less hassle
[02:28] <sarnold> keys++ :)
[02:29] <qman__> generate keys, add your public key to /root/.ssh/authorized_keys, done
[02:29] <Iskorptix_> from operator view yes, but not from the user
[02:29] <sarnold> oh yes, they're also far easier to audit after the faact :)
[02:29] <sarnold> Iskorptix_: heh, even on my blackberry, keys are easier. :)
[02:29] <qman__> but they are easier
[02:29] <Iskorptix_> one simple example
[02:30] <qman__> and anybody who doesn't think so really has no business using root access
[02:30] <Iskorptix_> or you know what, I think this discussion is going nowhere, not worth time waste ;)
[02:31] <sarnold> perhaps, you're not about to convince me that passwords are better :) I've been there, gave that up eight years ago.
[02:32] <qman__> keys have limitations, in that you have to have them with you to gain access
[02:32] <qman__> but that's a _good_ limitation
[02:32] <qman__> you don't want to log into your system from just any random machine
[02:33] <sarnold> not without otpw or something
[02:33] <qman__> if you think for even a second that that random hotel kiosk isn't keylogging you, you're sorely mistaken
[02:33] <qman__> yeah
[02:33] <qman__> OTP is the exception to that, but that's not easy to set up
[02:34] <qman__> if a machine is trustworthy, it's under your control or the control of someone you trust, and distributing keys to it or using them from a flash drive is simple and easy to do
[02:36] <Iskorptix_> one thing I know for sure is that there is no better replacement for authentication than radius
[02:36] <Iskorptix_> passwords, keys or anything else is just beyond that
[02:36] <qman__> that's fine for user logins, but you're talking about root
[02:38] <Iskorptix_> not sure what you mean ?
[02:38] <qman__> root doesn't belong in your centralized auth system
[02:38] <qman__> he's the local admin on each machine
[02:40] <Iskorptix_> ok, I would allow root access from the specific hosts ?
[02:41] <Iskorptix_> or, not sure would be wrong if I would allow direct root login from anywhere within the network if I would know that network is invisible to others
[02:41] <qman__> well, in a good setup, you'd only allow root access when absolutely necessary, like in a cluster
[02:42] <qman__> and you'd use sudo or su and a standard user account for admin purposes
[02:42] <Iskorptix_> sude is waste of time imho, not sure why debian flawors using it, but anyway, thats my oppinion
[02:42] <pmp6nl> Hello, what is a match block?
[02:42] <Iskorptix_> if someone already got single user access and trying to gain root, one day he will succed
[02:42] <Iskorptix_> is just a matter of time
[02:43] <sarnold> pmp6nl: from sshd_config ?
[02:43] <Iskorptix_> better think of "how to prevent bad guys inside network" not just how to secure root
[02:43] <pmp6nl> sarnold, yes
[02:43] <sarnold> Iskorptix_: :)
[02:45] <qman__> securing the network is important, but it's also important to secure in depth
[02:45] <qman__> allowing root access directly is forfeiting that layer of protection
[02:45] <qman__> you're putting all your eggs in one basket
[02:45] <Iskorptix_> you are looking into this from very short perspective
[02:45] <qman__> also, by using a non-root user and sudo, they have to guess two things, not just one
[02:46] <Iskorptix_> have you ever managed systems with lots of users ?
[02:46] <qman__> plenty
[02:46] <Iskorptix_> doesn't look so
[02:46] <qman__> we have over 2200 machines in our systems
[02:46] <qman__> at work
[02:47] <Iskorptix_> what I'm trying to say, is that you should look into this from broader view, not just than "how to keep root safe"
[02:47] <Iskorptix_> a good example could be two factor auth
[02:48] <Iskorptix_> and problem with root password is "relatively" shorted
[02:48] <qman__> keeping root safe is paramount to keeping your systems secure
[02:48] <qman__> and by not allowing root to log in, you're gaining almost as much as a two factor auth
[02:48] <Iskorptix_> you said that you have 2200 machines in your system
[02:48] <Iskorptix_> ok, I believe you
[02:48] <ScottK> Also if you use sudo, you get a log of who did what as root, which is very important when doing an autopsy on a multi-user system.
[02:49] <Iskorptix_> how many users accessing/managing such systems ?
[02:49] <qman__> you can also manage root access in an easy way with sudo
[02:49] <qman__> I don't actually know, going to guess about 3000
[02:50] <Iskorptix_> ok what happens when one or more than one user will become evil and will try to access protected data
[02:50] <Iskorptix_> will you get noticed about that ?
[02:51] <qman__> the file security isn't that tight on most of them
[02:51] <qman__> we can, however, look back at who did what, when, if asked
[02:52] <pmp6nl> Hello, I am trying to use unison to sync ubuntu server with ubuntu desktop.  unison keeps timing out (scanning takes too long?) Any ideas?
[02:52] <Iskorptix_> yeah, you will only find if user is pretty much short of unix systems
[02:52] <Iskorptix_> but if the "right" person will join your company, gain your trust and you give him root
[02:53] <Iskorptix_> you systems will be compromised and you wont get noticed about that
[02:53] <Iskorptix_> so concluding about what I'm arguing here is
[02:53] <qman__> you're arguing that by not securing root you're somehow defending yourself against corporate espionage
[02:53] <qman__> not following the logic there, to be honest
[02:54] <qman__> our systems don't do much to guard data over what's typical, but they have very good logging
[02:55] <qman__> and we have good backups
[02:55] <qman__> there's room for improvement, but keeping good practices is important to move in the right direction
[02:55] <Iskorptix_> simply I just saying that securing root is not enough, you should think about more security countermeasures
[02:56] <qman__> of course it isn't enough alone
[02:56] <qman__> but not securing root is like leaving your front door open
[02:56] <Iskorptix_> well, if you believe that loging and backups will save you against disaster, than I don't have to say much here
[02:56] <qman__> they don't avert disaster, they're for disaster recovery
[02:57] <qman__> and disaster recovery comes before averting disaster on the priority list
[02:57] <Iskorptix_> there are so many ways to breach the system, that only limit is the imagination
[02:57] <Iskorptix_> and backups and logs wont save your seat in plane
[02:58] <qman__> you can't prevent all disasters, but you can prepare for them
[02:58] <qman__> and keeping good backups and logs is easier than fixing every possible hole
[02:58] <qman__> so yes, backups and logs come first
[02:58] <Iskorptix_> that is why large corporations have dedicated people who work only on security within corporation, starting with employes and ending with everyone else
[02:58] <qman__> this is basic operating principle
[02:59] <qman__> you've picked the wrong person to lecture on security
[02:59] <Iskorptix_> [05:58:18] <qman__> you can't prevent all disasters, but you can prepare for them
[02:59] <Iskorptix_> that is just wrong, if you follow this then basically you do not know from where it comes
[02:59] <qman__> that's just a fact of life, things happen
[02:59] <qman__> you can't stop everything
[02:59] <Iskorptix_> so as I said earlier, if the right man is hired to compromise your system and if one of the job options is to delete everything
[03:00] <qman__> that doesn't mean you shouldn't try
[03:00] <Iskorptix_> then you are doomed
[03:00] <qman__> but you can't stop everything, and you have to be prepared for that situation
[03:00] <Iskorptix_> you can stop, if you do not know how, then its your problem
[03:00] <Iskorptix_> end of story.
[03:00] <pmp6nl> Should I be worried about:
[03:00] <pmp6nl> var/log/auth.log:Oct  7 07:44:31 bison sshd[23288]: reverse mapping checking getaddrinfo for 115.11
[03:00] <pmp6nl> 3.148.214.static-pune.vsnl.net.in [115.113.148.214] failed - POSSIBLE BREAK-IN ATTEMPT!
[03:01] <qman__> pmp6nl, only if you have a whole bunch of them
[03:01] <pmp6nl> qman__, I do, at least a few dozen
[03:01] <qman__> in which case you should implement some measure to restrict it, like fail2ban or -m recent on your firewall
[03:02] <pmp6nl> qman__, I have fail2ban installed.  I will look up -m?
[03:02] <qman__> pmp6nl, it's a module for iptables, the recent module, which can slow down incoming connections
[03:02] <qman__> but fail2ban should be plenty
[03:02] <qman__> make sure your passwords are strong, or preferrably, use keys instead
[03:03] <pmp6nl> qman__, I am using keys and no root.  I dont know if I configured fail2ban -- does that need much configuration?
[03:03] <qman__> no, the stock configuration is fine
[03:03] <qman__> it will allow a few attempts, then stop them
[03:03] <Iskorptix_> qman__, don't be upset, it just looks that you are looking into security thing that you have already lost a war
[03:03] <Iskorptix_> for example me, I love full control of things
[03:03] <qman__> the idea is to not allow nearly enough attempts to actually break in
[03:03] <Iskorptix_> starting from the first packet which comes within the network
[03:04] <pmp6nl> qman__, ok.  Should I still see all of those attempts in the log, even though i have fail2ban installed
[03:04] <qman__> Iskorptix_, it's impossible to defend against every possible attack
[03:05] <Iskorptix_> and if you have systems which has more users than you, then you should only use the things which fit the best, not only partially
[03:05] <qman__> not all possible attacks are even known, many are not possible to defend against, and many your users simply will not tolerate the defense of
[03:06] <Iskorptix_> qman__, can you imagine how people would react during job interview if candidate would answer with such pessimism ?
[03:06] <qman__> that is not an excuse to ignore best practices
[03:06] <qman__> it's not pessimism, it's fact
[03:06] <Iskorptix_> how can you know its a fact ?
[03:06] <qman__> your denying it shows your level of ignorance when it comes to security
[03:06] <qman__> pmp6nl, you should still see around 5-10 per attacker
[03:07] <qman__> but then they should stop after that
[03:07] <Iskorptix_> its not me, but its you
[03:07] <Iskorptix_> how you think most bussiest and largest internet systems keep running for years with being hacked ?
[03:07] <Iskorptix_> they thinked about every possible way of breach
[03:07] <Iskorptix_> simple as that
[03:08] <qman__> Iskorptix_, it's simple fact, new vulnerabilites are discovered daily; therefore, they were unknown the previous day, and therefore not defendable
[03:08] <sarnold> Iskorptix_: honestly, qman__'s "not all possible attacks are even known" shows that he's paid attention to the last two decades of security :)
[03:08] <qman__> as new vulnerabilites are discovered, they take time to fix
[03:08] <qman__> meaning known, but not defendable
[03:08] <qman__> and some vulnerabilies are by design in software your users need
[03:08] <Iskorptix_> vulnerabilites only dicovered if code is bad, but if code is ok, then there is no vulnerabilites
[03:08] <qman__> and therefore cannot be fixed
[03:09] <sarnold> ooof, never seen such head-in-the-sand-ism...
[03:09] <qman__> yeah
[03:09] <qman__> security, not just computer security, all security, is a matter of risk calculation
[03:09] <sarnold> qman__: btw, you may like to investigate pam_apparmor; it's not quite the tool I'd like it to be, yet, but it may help with locking users down to a subset of data...
[03:09] <qman__> defend well enough that most attacks will not succeed
[03:10] <qman__> and prepare to deal with a successful attack
[03:10] <qman__> because it will happen eventually
[03:11] <sarnold> ayup.
[03:11] <sarnold> see kernel.org.
[03:11] <sarnold> shoulda been tight and good. small user base. constrained needs..
[03:12] <pmp6nl> qman__, I saw way more than that: http://pastebin.com/JKiBWTLa
[03:13] <qman__> pmp6nl, yeah, looks like your fail2ban either isn't working or is set a bit too lax
[03:13] <qman__> check if it's enabled using sudo iptables -L
[03:13] <qman__> you should see a fail2ban chain
[03:14] <pmp6nl> qman__, http://pastebin.com/8YEyq2Nk
[03:15] <qman__> yeah, definitely enabled
[03:15] <pmp6nl> ok, do I need to change anything?
[03:16] <qman__> doesn't look to me like anything to worry about, check the fail2ban log, I think /var/log/fail2ban
[03:17] <qman__> it looks like that client opened a bunch of connections before authenticating to get more attempts in
[03:17] <qman__> even so, with that number of attempts, it'd take decades to brute force
[03:18] <qman__> you could adjust the fail2ban settings, or implement the recent module to further reduce that attack
[03:18] <qman__> but unless it looks like that all the time, with new attacks every few minutes every day, I wouldn't worry about it too much
[03:21] <pmp6nl> qman__, ok thanks. The log file looks like http://pastebin.com/ke1QdEnW
[03:22] <qman__> hmm, that doesn't look good
[03:22] <qman__> it was working but then it started producing errors
[03:23] <pmp6nl> qman__, any way to fix it?
[03:24] <qman__> oh, that error is in stopping, not starting
[03:24] <qman__> looks like it's working, it was just restarted a few times, probably a bug in the stopping portion
[03:24] <pmp6nl> ok thanks qman__  ... do you know anything about unison
[03:24] <qman__> rebooted or restarted fail2ban or your firewall recently?
[03:25] <qman__> no, I don't
[03:25] <pmp6nl> qman__, I think I may have.  I was having some ssh issue and running through a few things
[03:25] <qman__> ok, makes sense then
[03:25] <qman__> judging by that log, you may want to increase the ban time
[03:26] <qman__> looks like the same hosts are getting banned and unbanned a lot, so increasing that ban time would reduce the number
[03:26] <qman__> but, it's doing its job
[03:26] <pmp6nl> how do I increase the ban time?
[03:26] <qman__> should be a config file for fail2ban in /etc somewhere with those parameters
[03:27] <qman__> namely maxretry = 6, findtime = 600, and bantime = 1200
[03:28] <qman__> I'd increase the bantime to 2400 or 3600
[03:28] <pmp6nl> ok thanks. I will take a look.  Appreciate help!
[07:43] <henkjan> hmm, augeas lense for sysctl does not include /etc/sysctl.d/*
[07:43] <henkjan> not in precise, but even not in quantal
[09:09] <AdvoWork> just booted my brand new ubuntu server,and it came up like: login: init: plymouth-splash main process (442) terminated with status 1   any ideas please?
[09:22] <thierry_> good moning everyone!
[09:22] <thierry_> i've a question please! i need to disable login on start for my ubuntu-server
[09:23] <thierry_> so that i can get the shell command right away on start!
[10:09] <Daviey> I love the fact we install language-pack-gnome-en on precise. :/
[10:09] <RoyK> on server?
[10:10]  * RoyK diverts Daviey to https://bugs.launchpad.net/
[10:10] <Daviey> RoyK: I've added that to my bookmarks. Thanks.
[10:11] <koolhead17> Daviey: :P
[10:45] <jamespage> zul, bug 1062160 worthy of attention for quantal?
[10:55] <Daviey> FAILURE is not a package install option !
[11:10] <Ulfr> Hello all, I suspect Squid is the cause of a major bug I've been experiencing and I'm not at all sure how to go about troubleshooting it. Any advice?
[11:23] <zul> jamespage: yep
[11:23] <jamespage> zul, you ok to pickup?
[11:24] <zul> jamespage:  yep after i wake up :)
[11:25] <blackdex> Hello there
[11:25] <blackdex> why is anacron not installed by default on server edition but is on desktop editons???
[11:27] <patdk-lap> blackdex, cause you did something strange?
[11:27] <patdk-lap> it's installed on all of my servers, and I normally use the minimal install setting
[11:27] <blackdex> nope.. just a default install of ubuntu server 12.04 LTS
[11:27] <blackdex> i have it on multiple servers
[11:28] <patdk-lap> oh wait
[11:28] <blackdex> now the /etc/cron.daily etc.. didn't run
[11:28] <patdk-lap> it doesn't install anacron for me, but cron
[11:28] <blackdex> ok.. so it's not just me then :P
[11:29] <patdk-lap> my daily does run though
[11:29] <blackdex> hmm
[11:29] <blackdex> in /etc/crontab there stands this
[11:29] <blackdex> 25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
[11:30] <blackdex> but that doesn't seems to work
[11:30] <blackdex> strange
[11:30] <patdk-lap> I have the same
[11:30] <patdk-lap> and in my /etc/cron.daily I have stuff that updates files from the net
[11:30] <blackdex> it looks like it should run
[11:31] <patdk-lap> and those files are updates daily, just checked
[11:31] <blackdex> strange
[11:31] <patdk-lap> 2012-10-11 06:53
[11:31] <patdk-lap> in fact, happened just alittle bit ago :)
[11:32] <patdk-lap> you sure the script you put in there runs ok? without a user shell?
[11:34] <patdk-lap> ah, that is why it isn't installed
[11:34] <patdk-lap> anacron runs the /etc/cron.* stuff if the system is powered off
[11:34] <patdk-lap> since servers normally never poweroff, it's not really needed
[11:35] <patdk-lap> but it makes sure they run on desktops/laptops that are normally powered off during the time it would normally run those things
[11:35] <AlexO> Hey, I'm trying to open the 3306 port in order to acce to mysql from outside so I did : "iptables -A INPUT -p tcp --dport 3306 -j ACCEPT" but the port is still "closed" When i'm trying to connect using telnet on 3306 I get connection Refused any ideas?
[11:36] <patdk-lap> alex0, normally -A won't help
[11:36] <patdk-lap> -I would, if it's really a firewall issue
[11:36] <patdk-lap> but more likely mysql isn't listening on your external ip
[11:36] <blackdex> ah.. hmmmm
[11:36] <AlexO> -I is the interface right?
[11:36] <patdk-lap> did you check netstat?
[11:37] <blackdex> well thx
[11:37] <AlexO> patdk-lap: Yep he's listening
[11:37] <AlexO> it*
[11:37] <patdk-lap> to what ip?
[11:37] <AlexO> 0.0.0.0
[11:37] <patdk-lap> and a dump of, iptables -L INPUT -nv
[11:39] <AlexO> patdk-lap:  0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:3306
[11:39] <patdk-lap> that is the only line?
[11:39] <patdk-lap> I don't see the headers or anything
[11:40] <patdk-lap> plus, not the first two columns say 0, nothing matched that
[11:40] <patdk-lap> so the packets never arrived, or the other rules you didn't paste, blocked it
[11:42] <AlexO> patdk-lap: Sorry i though you just need that line, http://pastebin.com/Ban1WWaY
[11:42] <AlexO> ^ The whole thing
[11:47] <patdk-lap> default is accept, so it's not set to block anything anyways
[11:47] <patdk-lap> looks like the packets never arrive
[11:47] <AlexO> that's strange :/
[12:00] <AlexO> patdk-lap: I really don't get why it isn't working, this morning it was working, I did a nap, woke up and it's not working anymore (I mean I was able to connect to the base from outside telnet etc)
[12:58] <craigw> Can SELinux be easily installed on Ubuntu?
[13:00] <jcastro_> it's in universe
[13:02] <craigw> Can I enable universe for just that package?
[13:03] <jcastro_> enable it, install it, and then turn it off I guess
[13:04] <craigw> Ha, I hadn't thought of that, thanks
[13:21] <AdvoWork> I've just done cat /etc/passwd and i see testuser has id/gid of 1000 and postfix has id/gid of 1001. How can i swap these around? Trying to match them to another server.
[13:21] <zul> jamespage: ping
[13:25] <zul> jamespage:  this should be ok for swift right? http://pastebin.ubuntu.com/1273189/
[13:26] <jamespage> zul: looking
[13:27] <jamespage> zul: make it less that the version that the rejig happened in rather than less than or equal to the previous version
[13:27] <jamespage> that way if we have todo a SRU upgrades still work
[13:28] <zul> jamespage: so "<" ?
[13:28] <jamespage>  swift (< 1.7.4-0ubuntu1)
[13:29] <jamespage> even better would be the first version where this change happened
[13:29] <jamespage> but that may be lost
[13:29]  * jamespage looks
[13:30] <zul> jamespage: looks like 1.6.0-0ubuntu1
[13:32] <jamespage> zul, I concur so swift (< 1.6.0-0ubuntu1)
[13:32] <zul> jamespage: ack
[13:33] <jamespage> zul, I think you might want Replaces/Breaks rather than Replaces/Conflicts as well
[13:34] <zul> jamespage: done
[13:34] <jamespage> zul, you might wanna test that - I can never remember
[13:35] <jamespage> zul: << is the correct syntax as well
[13:36] <zul> jamespage: yeah going to test it first
[13:37] <jamespage> zul, go-oh
[13:48] <zul> jamespage: looks like we are good
[13:56] <zul> jamespage/Daviey: http://paste.ubuntu.com/1273255/
[14:09] <lunaphyte_> hi.  i'd like to enable core dumps for dovecot, but the things i've tried so far [ulimit -c unlimited and modifying limits.conf] don't seem to have worked.  how can i do this?
[14:21] <lunaphyte_> ah, figured it out.
[14:28] <lunaphyte_> setting ulimit -c unlimited in /etc/init/dovecot.conf seemed to get me what i'm after.
[15:34] <jstephan> hi there, trying to do a do-release-upgrade runs into "proxy ' ' looks invalid" has someone an idea how to fix that
[15:40] <RoyK> jstephan: echo \"$http_proxy\"
[15:40] <RoyK> or env|grep http_proxy
[15:40] <RoyK> perhaps that is set
[15:40] <jstephan> ah, got it, apt.conf has ist set empty
[16:15] <Subhranshu_> Hi All,
[16:15] <Subhranshu_> I am struggling with strange issue here regaing WUBI and XEN
[16:16] <Subhranshu_> i am having dual boot ubuntu 12.04 x86_64 with win7 using wubi
[16:16] <Subhranshu_> and i have just installed Xen on it
[16:16] <Subhranshu_> but it just do not boot in with xeb 4.1
[16:16] <Subhranshu_> XEN
[16:16] <Subhranshu_> and i cant either see menu.lst
[16:17] <Subhranshu_> Please suggest if some one know anything abt it
[16:19] <Subhranshu_> If some one could please suggest something that would be great help
[16:19] <Subhranshu_> please help
[16:22] <Subhranshu_> please sugets
[16:24] <sarnold> Subhranshu_: you haven't really said anything that anyone could use to debug your problem... you may wish to describe your setup and what specifically you changed between working -> non-working...
[16:26] <Subhranshu_> xm list ERROR:  Can't find hypervisor information in sysfs!
[16:26] <Subhranshu_> this is the error which i am getting
[16:26] <Subhranshu_> when i boot into ubuntu post installation
[16:26] <sarnold> are you confident you're running inside xen? or is sysfs not mounted?
[16:28] <Subhranshu_> see that is what the case is im not getting xen option on boot loader, i have tried this page https://help.ubuntu.com/community/XenProposed
[17:00] <gholms> soren: Any chance I could get uvirtbot to not snarf the bug links that eucabot sends to the channel?
[18:00] <hallyn> yeah that could be bad
[19:35] <_0x783czar> question, I'm trying to install an imap extension for php.  This extension fails it's configure command because it says that it needs to know where the Kerberos install prefix is.  I was wondering if anyone knows where I might look for this.
[19:39] <sarnold> _0x783czar: are you using kerberos? if not, better look for a way to disable kerberos support, maybe ./configure --without-kerberos or something simila
[19:40] <sarnold> _0x783czar: if you do need kerberos support, probably you'll need to install either libkrb5-dev or krb5-multidev or heimdal-dev or heimdal-multidev -- depending upon the details of your site
[19:44] <_0x783czar> sarnold: heimdal-dev seems to have provided the needed dependecy, thanks.  I hit another error with signatures, but that got me past that point, thanks!
[19:59] <stgraber> hallyn: what happens if you configure an interface and move it to another netns, does the config stick?
[19:59] <stgraber> (trying to figure out whether moving gives us the same as unplug/replug or if it's different)
[20:00] <stgraber> in the case where everything is flushed and you get a blank config, then it'd make sense for the kernel to emit net-device-remove. If the config sticks, then I'm not sure as you clearly don't want an interface to send you net-device-added with a pre-existing config (as that'd make ifupdown and likely some other things to fail)
[20:01] <hallyn> stgraber: i don't think that's the right thing to consider.  Rather, uevents are sent over netlink sockets which are only valid (i believe - though this may have changed) in initial netns
[20:02] <hallyn> of course this could be seen as another side-effect of lack of devicens
[20:02] <hallyn> so anyway, since uevents are sent over a netlink socket in some namespace, if a nic is moved to another ns, a -removed should be sent to the one and -added to the other
[20:03] <hallyn> yes, the config may stick - but it's up to the target to decide whether to keep it in my opnion
[20:03] <hallyn> bc in plenty of cases, the nic will be unconfigured, or configured wrongly
[20:03] <hallyn> most cases i'd say
[20:03] <hallyn> and so the target will want to be told it has this new nic which it should configure
[20:03] <hallyn> anyway for now we can certainly fake it in lxc,
[20:04] <hallyn> but i think we need a deeper discussion with kernel folks
[20:05] <hallyn> i'll send out an email
[20:07] <stgraber> hallyn: ok. anyway, time for my flight. ttyl
[20:07] <hallyn> stgraber: have a good flight!  ttyl
[20:21] <soren> gholms: I'm not sure I can make it ignore stuff from a specific user.
[20:21] <soren> brb
[20:22] <gholms> soren: It's a supybot, right?  Do you suppose its global ignore list would work with that plugin?