Noel Butler <noel.butler <at> ausics.net>
2011-07-20 07:51:57 GMT
On Mon, 2011-07-18 at 23:39 +0200, Gil Andre wrote:
On Mon, 18 Jul 2011 21:06:11 +1000 Nick Edwards <nick.z.edwards <at> gmail.com> wrote:
> Currently running Slack 12 servers.
> About to be migrating to ipv6, running dual stack.
Hmmmm... Maybe not such a good idea, dual stacks machines have been reported
as somewhat insecure.
How so? There is a lot of FUD going around. The risk is more so with ipv6 and thats only coz there's no more NAT, and lazy people rely on that for security where now they'll need to configure security on each device, so long as they remember that in dual stacking they need to replicate their iptables rules with ip6tables as well, and that's going to be the case for years to come, because ipv6 is here to stay and ipv4 will not vanish overnight, it may take up to a decade to see it gone.
It sounds like Nick needs those machines accessible anyway with 200 hosts.
> Is slack 13.37 inet1.conf script ipv6 ready?
> We have SSL hosts on servers so we need to up about 200 IP's, and in test it
> is fine if we use multiple /sbin/ifconfig eth0 inet6 add i:p:v:6:addy/64 in
> rc.local. but, for a modern OS, its kind of unheard of, bringing up
> interfaces via rc.local, especially since slack has a dedicated script file
> to do it.
That's all the network scripts do, just with a lil bloat
Be it with ifconfig or ip, you could just write your own network file called from rc.M right after it calls rc.inet1
We dont have a down script, but we dont want ours being down, only up. We call it just as a normal bash file (like rc.local) but don't use rc.local for safety reasons..
(segments deleted to protect the guilty)
/usr/sbin/ip -6 addr add 2:::::4/64 dev eth0
/usr/sbin/ip -6 addr add 2:::::5/64 dev eth0
/usr/sbin/ip -6 addr add 2:::::6/64 dev eth0
/usr/sbin/ip -6 addr add 2:::::7/64 dev eth0
/usr/sbin/ip -6 addr add 2:::::8/64 dev eth0
/usr/sbin/ip -6 addr add 2:::::9/64 dev eth0
NOTE: I hope you are prepared for the SSL certificate nightmares from hell ... unless you have a wildcard certificate for each domain that is. Hrmm these cert issuers are gunna make a killing aren't they... bastards.... or you could duplicate the apache entry and give me a self signed cert for ipv6... given the pittance that is ipv6 traffic, you probably could get away with it for a while.
Unless there is another way around it that escapes me, but given the IP's differ, I doubt it to avoid MITM warnings.
slackware mailing list
slackware <at> mailman.lug.org.uk