Well, I'd like to be. Seems someone got into my server - no damage caused aside from lost time rebuilding and making new certificates. My own fault probably as I had a flaw in my firewall script that let everyone through :O. Well, that's now been fixed, and I've moved to using OpenVPN to secure my wireless LAN instead of WEP. So it's now as secure as I can make it :)Infact, using OpenVPN I can now connect my laptop to my home network very easily - the only downside is that I'm struggling a little with IPv6 routing across the TAP interface. I can ping either end OK with addresses configured by radvd, but routing for some reason does not work :? Oh well.Aside from that, I'm unsure about how to get my XBox onto my wireless LAN now. I think the only thing I can do is forward and resolve names insecurely for my Xbox MAC address and just allow that. Ideas on a postcard are welcome :) But no cookies as I hardly use the thing anymore except to play DVDs ...
OK, say you have a dhcp connection to the LAN which supplies generic name servers (ie internet). Now you want to create a VPN connection to your home LAN and use its nameservers so you can ping the right machines at home. At the moment, you can't. openvpn in portage currently has no ability to even create /etc/resolv.confWell, it has now. Well, it will when I upload it (don't ask when as it depends on other stuff being done first). More importantly it also supports the up-coming resolvconf I blogged about earlier. This is all well and good, but libc won't work like we want - if we want a vpn name and the first server that responds isn't on the vpn then libc won't even try the other servers. Infact, all dns servers/caches/whatever work like this so it's not a new limitation.But there is a workaround - dnsmasq can forward queries to a specific nameserver for a specific domain. So we inform dnsmasq of this like so using a resolvconf plugin.If an interface resolv.conf file contains the "domain" directive, then forward requests for that domain to the specified nameservers only. Otherwise, treat it as a generic nameserver.Of course, this requires a little change to the dhcp clients (dhcpcd, udhcpc, pump and dhclient) to only fill out the search part.EDIT: bind can do this too, as such I've written a bind plugin that works in the same way. The setup is a little more complex, but do-able.
baselayout-1.12 forces all dhcp clients to store its resolv.conf in their own locations so they didn't overwrite each others. It even merged them all together. This works very well. :D
So along comes openvpn with its ability to use an unspecified tun/tap interface (if tun0 is in use it will use tun1, etc) and that wanting to setup it's own resolv.conf too (not that current portage one does this, but next one will ;) ). The nice thing about openvpn as it is right now is that it doesn't rely too much on baselayout, and I would like to keep it like this so that when other packages come along that want to say "here, use this dns information now" we have an easy way for them not to stamp on each others toes.
So I got thinking. Gentoo can't be the only distro that has this problem, so I looked around some. I found Debians resolvconf which does pretty much what baselayout did with resolv.conf but provided a generic framework for managing it. This is what I've been looking for as it also provided a framework for subscribers to be notified of a resolv.conf change, something that my solution did not. This means that no-one should have to do a /etc/init.d/nscd restart in their conf.d/net postup anymore :)
So I'm writing a resolvconf for Gentoo at the moment, taking the best bits of baselayout-1.12 (better merging and interface selection based on metrics) and Debians resolvconf (command line compatibility and subscriber framework). Once I get that into portage, I'll be patching baselayout, our dhcp clients and things like openvpn to use it.
I'm also thinking that instead of patching dhclient for dbus support for up and coming NetworkManager support it's probably a better idea just to write a !NetworkManager subscriber for resolvconf which means !NetworkManager could in theory work with any dhcp client :)
I've been playing around with openvpn some more now, trying to get it to behave nicely as a server and a client with the minimum of fuss from a user perspective. Well, the server part it easy - it goes up or not ;)
The client part however is a little more complex ...... So what I've been working on is a set of scripts that mimic baselayout-1.12's inactive status so that the openvpn daemon can instruct the init script that authentication was successfull and mark it as started. This is great as it means you don't have to know the ip at the other end and ping it like the old init scripts did. So if you missed that feature, don't panic it's coming back :)
It works in a very simple way too, simply by using
--up --down <script> --up-delay --up-restart flags if we're a client (detected by specific options in the selected config).
Whilst eating a toffee sweet (yes, bad boy!) it kinda stuck to one of my fillings and took it out :sick:. So, me minus a big filling, I went in search of a dentist. Guess what! There's no NHS dentists anywhere near where I live. Bah. So I found a reasonably priced dentist near work and went along.The good news - my filling has been restored. The bad news, I need two crowns. This is gonna cost be just short of a grand :jawdrop:. "Bugger", said I. I'm not too suprised that I need 2 crowns as there's been hardly anything left of the 2 teeth in question for a few years now and have been mainly just filling.Well, I now have my temporary crown on one of my teeth (doing one at a time to spread payment across months) and I get my proper crown in 2 weeks time.Moral of the story - get dental insurance!