[00:01] <Kimse> Anybody here ever tried to use automount inside a NAT'd LXC container to mount home directories shared via NFS? Can't get it to work on a NATd container
[00:01] <twb> Waaaay back in 10.04, if you installed screen, it would pull in update-notifier-common, which would change the MOTD to remind you if there was a newer kernel to reboot into.
[00:02] <twb> Can anyone tell me offhand if that's still the case?
[00:02] <twb> That is: if I install update-notifier-common, will MOTD start warning about pending kernel updates
[00:02] <twb> (I suspect this used to happen via byobu, and I have no idea what's happened in byobu.)
[00:12] <tarpman> twb: yeah, update-notifier-common still does the motd updating stuff
[00:12] <twb> Cool, so I can install just that and get that feature
[00:13] <tarpman> http://packages.ubuntu.com/xenial/all/update-notifier-common/filelist
[00:13] <twb> Thanks
[00:14] <tarpman> twb: I think you might also need update-motd installed, if you don't already have it (looks like it's recommended by libpam-modules)
[00:15] <twb> I'll find out if this change request gets approved :-)
[00:37] <capitanocrunch> hello
[00:39] <capitanocrunch> im newbie playing with ubuntu server 12.04
[00:40] <capitanocrunch> i want to setup dns server but /etc/init.d/bind9 start fail
[00:41] <twb> Unless you need to stick with 12.04, it is a good idea to install a newer release --- 14.04 will be supported for longer than 12.04.  And I guess 16.04 is due out next month.
[00:43] <capitanocrunch> the issue with bind9 is: bridge.grumpy-troll.org/2012/05/pangolin-update/
[00:44] <capitanocrunch> so if i upgrade the distro, it will work without no fix/workaround needed?
[00:57] <twb> Don't know :-)
[00:57] <twb> I use nsd3 rather than bind.
[00:57] <twb> (But I'm weird, and I'm not a regular here.)
[00:58] <twb> From the URL you gave, it's not clear to me what the issue is
[01:57] <karstensrage> how do you guys deal with updating distros
[01:57] <karstensrage> for many many servers
[01:57] <twb> if $boss has his way, we just don't :/
[01:58] <karstensrage> are LTS -> LTS updates reliable?
[01:58] <twb> Assuming you use do-release-upgrade, they should be.
[01:59] <twb> I've blown my foot off once or twice by doing something it didn't expect, like writing "auto lo eth0" in interfaces(5), which the upgrade script didn't understand.
[02:00] <karstensrage> its seems like there could me a lot of stuff that has to manually updated if you change anything
[02:01] <inteus> yeah, mmight be a bit more difficult if you have a lot of customization
[02:01] <twb> In Debian, weird things are just documented.  In Ubuntu, do-release-upgrade tries to automate it with scripts.
[02:01] <twb> The weirder you are, the more likely the scripts are to fall over.
[02:01] <twb> Because I'm very weird, I prefer the Debian approach :-)
[02:02] <twb> I also had problems where if do-release-upgrade crashed halfway, it didn't make any attempt to roll back
[02:03] <twb> Since most of my gear is stuck of 10.04, I can't comment on recent upgrades
[02:05] <karstensrage> seriously?
[02:05] <twb> ya: 12:57 <twb> if $boss has his way, we just don't :/
[02:06] <karstensrage> i get so much shit from the packaging community about wanting to put my packages on natty and saucy
[02:07] <karstensrage> i keep telling them its not realistic to expect everyone to be on the latest
[02:07] <karstensrage> i really dont like packaging
[02:16] <twb> "it's behind a firewall so it doesn't matter if it's EOLd"
[07:14] <nocontrol> can anyone please help http://stackoverflow.com/questions/35221886/export-foreman-workers-from-rails-app-to-systemd ?
[07:15] <twb> "foreman" is some kind of software?
[07:16] <nocontrol> yes, it's awesome
[07:17] <twb> What version of systemd do you have?  systemctl --version
[07:18] <twb> Unfortunately systemd's "No such file or directory" doesn't tell you *which* file it failed to access.  It could be seriapp.target, or some underlying file.
[07:18] <twb> The fact that "systemctl start seriapp" reports seriapp.target instead of seriapp.service is suspicious.
[07:19] <twb> What systemd units are you using / have you written?
[07:19] <nocontrol> twb: systemd 215
[07:20] <twb> Also you wrote "export systemd /etc/init", which seems wrong to me -- /etc/init is for upstart, not systemd
[07:20] <twb> systemd jobs typically go into /etc/systemd/system/
[07:20] <nocontrol> twb: I've done it wrong but now rvmsudo foreman export systemd -a seriapp -u deploy says I must specify a location
[07:20] <nocontrol> twb: yes I removed that
[07:20] <nocontrol> hmmm should I try with /etc/systemd/system ?
[07:21] <twb> I don't know.  It is not clear to me what your setup currently looks like.
[07:21] <twb> It sounds like you made several mistakes at once, fixed some, and some are still there
[07:21] <twb> Can you pastebin a summary of what your system looks like right now?  e.g. "systemctl", "systemctl cat seriapp.service" "systemctl cat seriapp.target", &c
[07:22] <nocontrol> twb: I 've looked for a log file but it seems there isn't any in /var/log
[07:22] <twb> systemd writes to a "journal", this starts out in /run and moves into /var/log/ later.  You read it with "journalctl" rather than by catting files in /var/log/.
[07:22] <twb> If you are using rsyslog (or similar), you might ALSO have logs copied back out of journald into traditional logfiles
[07:23] <nocontrol> twb: systemctl cat seriapp.target doesn't return anything
[07:23] <nocontrol> journalctl -> No journal files were found.
[07:24] <twb> That is interesting.
[07:24] <tiblock> Hi. Is there software to automaticaly restart script that exit. I know you can use bash for this, but is there some package for that?
[07:24] <twb> nocontrol: what environment is this?  e.g. a regular Ubuntu 14.04 install, or what
[07:24] <twb> tiblock: there are many ways to achieve that, which to use depends on your specific case
[07:24] <nocontrol> twb: tbh it's a raspbian
[07:25] <twb> nocontrol: for raspbian, this is the wrong place
[07:25] <twb> !raspbian
[07:25] <tiblock> twb, i just need to start binary file again when he crashes.
[07:25] <nocontrol> twb: does it have any difference ?
[07:25] <twb> On #debian it says: 18:25 <dpkg> Raspbian is a distribution <based on Debian> made specifically for the <Raspberry Pi>.  Raspbian is not Debian and it is not supported in #debian.  Please use #raspbian on irc.freenode.net for support.   http://www.raspbian.org/
[07:26] <twb> nocontrol: I don't actually know!  That makes it hard to support :-)
[07:26] <twb> tiblock: if it is a daemon, you can tell upstart or systemd to restart it
[07:26] <twb> tiblock: if it is something like rtorrent, then the best way is different
[07:27] <twb> nocontrol: you could also try asking the foreman or ruby communities, or #systemd.
[07:27] <tiblock> twb, its not daemon, its handmade thing. I mean if i do "./prog" then when it chashes nothing happens. I want "relaunch ./prog" so it will restart on crash. Is there such "relaunch" software?
[07:28] <twb> tiblock: hrm... I don't know of a good one
[07:28] <twb> tiblock: here is one I wrote years ago: http://cyber.com.au/~twb/.bin/twb-loop
[07:28] <tiblock> twb, okay, will use .sh scripts. Thank you
[07:28] <twb> The simplest is: while ! ./prog; do sleep 1; done
[07:29] <twb> But that does not do exponential backoff, logging &c
[07:30] <twb> tiblock: you can ask #bash for help with writing scripts like this, but be aware they can be grumpy and rude :-)
[08:33] <lordievader> Good morning.
[11:15] <Kimse> Anybody here who can help me with an autofs/lxc issue: http://askubuntu.com/questions/729950/automouting-nfs-share-inside-natd-lxc-container-fails ?
[13:12] <sb_9> hi folks
[13:19] <sb_9> http://pastebin.com/UEyE83Ak
[13:25] <teward> sb_9: iptables and ip6tables need to be configured individually
[13:25] <teward> sb_9: so for permitted v6 addresses, you have to add ACCEPT rules for those sources going to that port
[13:26] <teward> sb_9: i.e. ip6tables -I INPUT 1 -s ipv6-address -p tcp --dport 2070 -j ACCEPT
[13:26] <teward> it looks like you already have one such rule in place though
[13:26] <sb_9> teward: configured ipv6 tables to allow the known ipv6 address. But DROP Rule from Ipv4 fireall configuration is rejecting the connection.
[13:27] <teward> sb_9: no, because v6 goes through ip6tables rules
[13:27] <teward> NOT iptables
[13:27] <teward> trust me, assuming iptables handled both v4 and v6 is how I got breached through the v6 IP on one of my VPSes
[13:27] <teward> sb_9: are you getting timeouts or just "connection refused"?
[13:28] <teward> connection refused could mean it's not listening on v6
[13:28] <sb_9> teward: it allowed to make a connection when i removed the DROP rule from iptables.
[13:28] <teward> sb_9: that's likely because you're not using v6 as expected
[13:28] <teward> sb_9: if the iptables rule is blocking, then you're going over v4, apparently
[13:28] <sb_9> teward: did i configured ipv6 wrongly.
[13:28] <teward> ip6tables is the one that would be handling v6
[13:29] <teward> sb_9: i can't say, i'm not at your location to do diagnostics - you have to make absolutely certain that the computer initiating the connection to the system is in fact using IPv6
[13:29] <teward> for that connection attempt
[13:29] <sb_9> teward: i have configured ipv6, but it is not working as i expected.
[13:30] <teward> sb_9: configured on the server, or the system you're using to reach to port 2070 on the target server?
[13:31] <sb_9> teward: configured on the server.
[13:31] <teward> i'm not talking about the server
[13:31] <teward> i'm talking about the client you're on
[13:31] <teward> I.E.
[13:31] <teward> which system is connecting to the server at port 2070
[13:32] <teward> sb_9: telnet -6 SERVERIPV6ADDRESS 2070
[13:32] <teward> after putting that iptables rule back in place
[13:32] <teward> if it works, then you know it's not an issue with the v6 on the server
[13:33] <teward> (yes it may not be telnet, it's just one way to see if there's a connection that can get through)
[13:33] <sb_9> teward: then what should be the issue. do you mean client system is trying with ipv4 connection?
[13:33] <teward> yes that's exactly what i'm saying
[13:33] <teward> sb_9: if the client system doesn't have proper v6 it may be falling back to v4
[13:34] <sb_9> teward: i am testing with telnet only. but didn't tried  option   -6 .
[13:34] <teward> in which case ip6tables wouldn't see it and iptables would
[13:34] <teward> sb_9: use -6 - it forces IPv6
[13:34] <teward> sb_9: the client system you're using - does it have proper working v6?
[13:35] <sb_9> teward: since my client is trying to connect it. i just asked to send him the ip address shown by Google. "my ip address".
[13:36] <teward> make sure it's showing an ipv6 address
[13:36] <teward> and if it is, then use `telnet -6` to *force* Ipv6
[13:36] <teward> if it's still not working, then it could be a client-side configuratin
[13:37] <teward> but if you don't *know* that you have properly-working IPv6, then that may be the issue
[13:37] <sb_9> teward: it is showing ipv6 address only.
[13:37] <teward> sb_9: with -6 does it try and connect?
[13:37] <teward> (you never answered that heh)
[13:38] <sb_9> teward: not yet. need to do. But if it fails?
[13:38] <teward> then remove the ip6tables DROP rule and try again
[13:38] <sb_9> teward: to test that I need to connect my client system
[13:38] <teward> if it still fails, it may be your client system that's not doing v6 right, through whatever connection is in place
[13:39] <sb_9> teward: okay. let me try it.
[13:39] <sb_9> teward: thanks for your suggestion.
[13:42] <teward> whee, power outage >.>
[14:09] <m1dnight_> I have a server here at my lab which keeps getting zombie processes.
[14:10] <m1dnight_> How can a process become a zombie process and not be collected by init?
[14:10] <m1dnight_> Can the application itself cause that?
[15:41] <necrophcodr>  alright, i have a huge issue with postfix and virtualmin. I've got a virtual and canonical mapping going, and I want to restrict sending email to ONLY be allowed from addresses in virtual/canonical db
[15:41] <necrophcodr>  currently i've used smtpd_sender_restrictions = reject_unauth_pipelining permit_mynetworks permit_sasl_authenticated reject_unauth_destination reject_unlisted_sender reject_rbl_client cbl.abuseat.org reject_rbl_client zen.spamhaus.org reject_rbl_client bl.spamcop.net
[15:41] <necrophcodr> i know a bit about how postfix works, but this one has me tied
[15:41] <necrophcodr> i've read the ubuntu docs, and the postfix manuals including postconf(5)
[15:45] <sdeziel> necrophcodr: you could probably add a check_sender_access (http://www.postfix.org/postconf.5.html#check_sender_access) to your smtpd_sender_restrictions
[17:10] <necrophcodr> alright, so having a canonical and virtual db setup with postfix, how do you use that to reject emails being sent from the server, not listed in those db?
[17:11] <necrophcodr> it can be as restrictive as possible or not, as long as only those in canonical/virtual maps are allowed to send
[17:14] <sdeziel> necrophcodr: make the DB lookup via the check_sender_access restriction
[17:15] <necrophcodr> sdeziel: is that really absolutely the only way? i mean if it is, it's what i'm gonna have to do, although that requires a different db
[17:19] <sdeziel> necrophcodr: maybe this would be better suited: http://www.postfix.org/postconf.5.html#reject_unlisted_sender
[17:22] <necrophcodr> sdeziel: the following is what i've been using
[17:22] <necrophcodr> smtpd_sender_restrictions = reject_unlisted_sender, reject_non_fqdn_sender, reject_unknown_sender_domain, reject_unauth_pipelining, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject
[17:22] <necrophcodr> it wasn't enough
[17:28] <sdeziel> necrophcodr: odd. Maybe you could try debugging this with debug_peer_list. I'd also recommend checking postfix own IRC channel (if any) and/or the mailing list as I'm not familiar with postfix DB integration
[17:29] <necrophcodr> sdeziel: thanks, i'll give both a shot.
[18:01] <kuly-zu> when i run netstat i saw some PID/program-name has a -, even if it's run with sudo, why?
[18:02] <teward> !crosspost | kuly-zu
[18:04] <sdeziel> kuly-zu: connections opened by the kernel shows has having a prog name of "-"
[18:13] <daum_> hey guys - is there a good guide for the tuning of a server for high network activity.  We have a micro http service that is getting around 150k req/sec then makes at least one db request per to our db cluster over a second nic.
[18:14] <ikonia> what is your current network through put
[18:14] <ikonia> how big is each request
[18:14] <ikonia> what does the processing of that request
[18:15] <daum_> looks like 38MiB RX, 31MiB tx on the http bound interface, then 15MiB rx and 26MiB txt on the DB facing interface
[18:15] <daum_> ikonia, the http requests are simple get requests
[18:15] <ikonia> yes but what do they do
[18:15] <daum_> processed by a netty app
[18:15] <ikonia> whats serving them
[18:16] <ikonia> what is load thats creating
[18:16] <ikonia> how many requests are those stats for
[18:16] <daum_> load right now is about 33% of capacity
[18:16] <daum_> 150 req/sec  is the stats above
[18:16] <ikonia> what makes you think it won't scale up ?
[18:16] <daum_> just trying to look into tuning the network side same point we're tuning our app more
[18:17] <ikonia> I think you'd need to look at a problem to "fix" rather than "generic" tuning
[18:17] <ikonia> as what you change for A impacts B
[18:18] <daum_> true makes sense
[18:19] <daum_> i guess one question would be what to look for that points to network issues vs app level
[18:20] <ikonia> it will really depend on the behaviour
[18:20] <ikonia> depending on what's happening you'll get a few tell tail signs
[18:20] <ikonia> but it depends on the situation,