[03:27] <DirtyCajun> sarnold, that is an interesting way to go about it... ill look into it in the morning. Basically regenerating the conf file every edit... Very out of the box! i like it
[05:54] <Henster> Morning, I'm copying over allot of files and i want the system to email me when the job is done ? i do have emails set up ,can some one please point me in th ecorrecti direction?
[05:55] <Henster> the correct*
[05:59] <sarnold> if the 'mail' command actually works correctly you can try cp a* b/ ; echo done | mail -s done username@example.com    (at least I think that's how mail works, it's been a while)
[06:22] <Henster> ok cool tx , will try
[07:05] <blind_techie> Hi All, looking for some help getting wi-fi setup on my little portable server.
[07:07] <blind_techie> I'm looking to have it create a wi-fi access point if it is not connected to the network so that I can then connect it to the network by inputing credentials into its web interface.
[07:07] <blind_techie> Any pointers on where to start.
[07:09] <sarnold> blind_techie: I've never tried it myself but I think hostapd is a reasonable starting point for making a standard linux machine pretend to be an access point http://w1.fi/hostapd/
[07:10] <lordievader> Good morning.
[07:10] <lordievader> blind_techie: Hostapd is a very nice way of creating an access point, granted your wifi nic supports master mode.
[07:11] <blind_techie> Thanks. I'll check it out. What about using NMCLI?
[07:12] <lordievader> NetworkManager has AP support?
[07:12] <lordievader> Wait, why am I surprised?
[07:13] <lordievader> blind_techie: https://wiki.archlinux.org/index.php/software_access_point
[07:13] <lordievader> Arch also goes the hostapd route.
[07:14] <blind_techie> I'm not sure how easy it would be to get the server to become a network client with this setup. IE. I'm not sure hostapd will allow the server to stop broadcasting, connect to the website and then return to hosting if it fails.
[07:16] <sarnold> I'd expect it to be difficult to get the details right
[07:16] <blind_techie> I'll try the method in the second link.
[07:17] <sarnold> but it should be possible to write a little program that manages hostapd and iwconfig and wpa2_supplicant and a simple webservice, say sinatra or flask or a little go server, and manage state transitions among all the inputs.
[07:18] <blind_techie> node.js perhaps. Hmm!
[07:19] <blind_techie> I found this package https://www.npmjs.com/package/wireless-tools
[07:20] <sarnold> wow, that looks like it knows how to drive everything.
[07:21] <sarnold> alright, bedtime here. have fun. :)
[07:21] <blind_techie> Thanks.
[07:21] <blind_techie> Night night!
[07:21] <sarnold> thanks :)
[07:22] <blind_techie> No problem.
[07:22] <lordievader> blind_techie: It is easier to make a dedicated access point.
[07:22] <lordievader> The management of your requirement sounds like a pita.
[07:23] <blind_techie> It is for installation on a single board computer where we have one card for wireless. The point is to allow the device to be configured by a smartphone or tablet and then connect to the internet by itself.
[07:45] <snypz> hello all
[07:54] <lordievader> o/
[14:47] <Pinkamena_D> kind of out there request but anyway: I have a development server where I have many (python) web apps running on different ports and I have other people test things on this machine. From my local workstation I have a bash script that pushes new updated to these servers. The web apps are run in a screen session with console output so that if some error happens I can quickly look at it and debug it. However after the
[14:47] <Pinkamena_D>  updates are pushed I have to ssh and restart the process manually to see the updates. Is there any way to restart the process in the screen session automatically? (equiviliant to attaching to screen, pressing ctrl c, up, enter)
[14:49] <rbasak> Start with a post-receive hook
[14:49] <rbasak> (in git)
[14:50] <rbasak> Making the thing restart inside the screen session is a little trickier
[14:50] <rbasak> You might need to wrap it with something that'll interact with the post-receive hook.
[14:50] <rbasak> I can't think of anything similar while still keeping it inside a screen.
[14:50] <rbasak> Some web frameworks have an auto-restart function, like cherrypy. So an alternative might be to integrate that into your code.
[15:09] <admcleod> xibalba: jemurray (or anyone else) - any idea if the IO load is particularly high right now?
[15:09] <admcleod> er... ^ ignore
[17:36] <drab> hi, anybody running bonding? I'm seeing what look like a problem with the ifup scripts
[17:36] <drab> if I ifdown the bond, it takes all the slaves down, which is fair enough I guess
[17:37] <drab> however if I ifup the bond, the slaves aren't brought up even tho they are specified as slaves for the bond in /etc/network/interfaces
[17:37] <drab> as a result network is broken on the box
[17:37] <drab> I have to manually bring the slaves up and then it works
[17:37] <drab> shouldn't that happen automatically as part of ifup?
[17:47] <patdk-wk> how did you configure it?
[22:09] <drab> is there any irc channel or ml/forum to ask hard server questions? having some problems and not quite sure where to turn to
[22:09] <drab> stuff like spiceworks seems rather generic and ubuntu-server seems dead silent/only server dev oriented which is fair enough
[22:14] <patdk-lap> haven't seen you ask anything
[22:15] <patdk-lap> you ignored my question to help you earlier
[22:16] <nacc> drab: --^
[22:17] <nacc> drab: there's #linux (iirc -- maybe ##linux)
[22:20] <drab_> patdk-wk: hi, got disconnected again, didn't mean to ignore you, been a very flacky internet day
[22:20] <drab_> I never saw your msgs
[22:20] <drab_> I think I always responded in the past whenever you asked questions and I'm grateful for all the help
 how did you configure it?
[22:21] <patdk-lap> there are so many ways to setup bonding in /etc/network/interfaces
[22:24] <drab_> patdk-wk: sec, pasteb'ing, thanks
[22:32] <drab_> patdk-wk: http://paste.debian.net/924212/
[22:32] <drab_> this actually works (it was the last attempt I made)
[22:32] <drab_> it's a bridge for lxd on top of a bonded quadnic
[22:33] <drab_> and since I added the bridge with the up ifconfig eth* up things have improved
[22:33] <drab_> before I only had the bond with the lxdbr0 attached to it
[22:33] <drab_> maybe I should have had the "up" statements in there too?
[22:34] <drab_> I thought that since I had the auto and the master/slave statements the slaves should have been brought up and joined automatically
[22:36] <drab_> but if I do ifdown bond0 and ifup bond0 it says waiting for slaves to join, but they never do
[22:43] <patdk-lap> I don't use the bond-slaves line at all
[22:46] <drab_> patdk-wk: ok, I can try to take it out and see if it makes a difference, I got that from the ifenslave readme, I was actually hoping to use only that one without bond-master since it simplified the gen of interfaces file, but it didn't work without
[22:46] <patdk-lap> up ifconfig bond0.4 up
[22:46] <patdk-lap> that I do have to do on my bridges though
[22:46] <drab_> ok, I have that too, up ifconfig bond0 up
[22:46] <patdk-lap> no, cause it won't setup the other interfaces
[22:46] <drab_> the bridge on top of the bond seems to work fine, the problem seems to be the slaves of the bond not coming up
[22:46] <patdk-lap> I do not have any of the other ifconfigs at all
[22:47] <patdk-lap> ya, I blames your bond-slaves line
[22:47] <drab_> but I'm trying without the slave statement to see what happens
[22:47] <drab_> k
[22:47] <drab_> testing, thank you
[22:47] <drab_> btw I got that idea from /usr/share/doc/ifenslave/README.Debian.gz
[22:47] <patdk-lap> actually
[22:47] <patdk-lap> I have bond-salves none
[22:47] <drab_> but maybe I misread it
[22:47] <drab_> ah, uhm, oikj
[22:48] <drab_> patdk-wk: so you don't have any up ifconfig $slave_iface up at all in the bond stanza or elsewhere?
[22:48] <drab_> they just come up?
[22:49] <patdk-lap> http://paste.debian.net/924213/
[22:51] <drab_> thank you, great example
[22:52] <snypz> hello all
[22:52] <drab_> hello snypz
[22:58] <drab> patdk-wk: got kicked out again. same behavior with slaves none
[22:58] <drab> everything comes up and works at boot
[22:58] <drab> but if I do ifdown bond0 it dowsn the slaves too
[22:58] <drab> but ifup bond0 doesn't see any slaves joining
[22:58] <drab> I have to manually bring them up
[22:59] <drab> so same situation as before with the slaves statement referencing all the slaves
[22:59] <patdk-lap> oh, that won't work
[22:59] <patdk-lap> cause they are set to manual
[22:59] <patdk-lap> you have to manually up and down them
[23:00] <patdk-lap> the auto just works on boot to ifup them
[23:00] <drab> ok, fair enough, that's what I suspected, but I wondered if there was automagic I was missing since they are brought up "magically"
[23:00] <patdk-lap> only way I know if you care about that is to setup a bunch of pre-up and post-down commands or somethign like that
[23:00] <drab> yeah, that's what I was trying last
[23:00] <patdk-lap> they are not really brought up automatically
[23:01] <patdk-lap> the auto means, when the os sees the new nic, it ifup it
[23:01] <drab> to have a bunch of up ifconfig eth* up in the bond stanza, similarly to what you also have in the bridge
[23:01] <patdk-lap> you would have to add a down one there
[23:01] <patdk-lap> then probably add some up and downs to the bond
[23:01] <patdk-lap> personally I never do that stuff
[23:01] <patdk-lap> cause I need it up, and only up
[23:02] <drab> heh
[23:04] <drab> patdk-wk: how's the jumbo frame stuff working out for you btw? have not set that up because I don't have 100% quipment supporting it and I can't figure out from the interwebs if mixing is a bad thing or not
[23:04] <drab> so for some server-to-server stuff that'd be fully supported, but from clients/desktops some switches in the path won't
[23:04] <patdk-lap> never use anything else
[23:04] <patdk-lap> heh?
[23:04] <patdk-lap> the whole network has to be jumbo or not
[23:05] <drab> ok, fair enough
[23:05] <patdk-lap> you can't mix up mtu's on the same network
[23:05] <drab> I have some leaf switches that aren't, close to ppl's workstations
[23:05] <patdk-lap> everything at amazon switched to jumbo a few years ago
[23:06] <drab> good stuff
[23:06] <patdk-lap> only if your switch can handle it
[23:06] <drab> I consider myself lucky we finally have servers and not old desktops running all our services :)
[23:06] <patdk-lap> it plays hell on microbursts with switches limited buffers for gigabit
[23:40] <drab> is there any way in udev rules to match physical interfacels only?
[23:41] <drab> in /etc/udev/rules.d/70-my-net-names.rules
[23:41] <drab> SUBSYSTEM=="net", KERNEL=="e*" ACTION=="add", ATTR{address}=="xxxxxxx", NAME="eth0"
[23:41] <drab> initially I had no KERNEL=="e*"
[23:41] <drab> and that caused troubles with the bridge which was going to take the mac of eth0
[23:42] <drab> I added KERNEL=="e*" and that fixed the issue and works on a few servers which would normally come up with enp* and em* interfaces
[23:42] <drab> however on another machine there's some network devices named p*
[23:43] <drab> it'd be useful to be able to just refer to "physical" interfaces vs sw ones like bonds or bridges
[23:43] <drab> but I don't see how to do that
[23:43] <nacc> drab: if you can programmatically determine that, you can use PROGRAM
[23:48] <patdk-lap> why do you want to name all of them manually?
[23:48] <patdk-lap> if you want to do that, why not just uninstall the naming package?
[23:49] <patdk-lap> did that thing get renamed or something?
[23:49] <patdk-lap> used to be called something like biosdevname or something
[23:49] <drab> patdk-wk: it happens without biosdevname installed
[23:49] <patdk-lap> ya, systemd does it
[23:50] <drab> the naming becomes odl style again if I pass net.ifnames=0 and biosdevname=0
[23:50] <drab> but that creates a different set of problems
[23:50] <drab> so renaming with udev is still the "best", altho that is now also creating issues..
[23:50] <drab> if I don't rename them there is a bug in netcfg and I can't do pxe installs
[23:52] <patdk-lap> I would recommened, not hitting bugs