[gentoo-user] cyrus-sasl necessary with localhost webmail?
I recently switched from Thunderbird to Roundcube (highly recommended), switched to the non-SSL courier daemon, and plugged the firewall hole since courier resides on the same system as my web server. Do I still need cyrus-sasl or will a webmail client authenticate directly with courier? I have authmodulelist=authshadow in /etc/courier/authlib/authdaemonrc. - Grant
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On 11/03/2013 06:00, Walter Dnes wrote: On Sun, Mar 10, 2013 at 05:07:25PM -0400, Michael Mol wrote NAT behind a home router is bad, too. For IPv4, it's only necessary because there aren't enough IPv4 addresses to let everyone have a unique one. The best real reason for moving to IPV6 is address space (or lack thereof, in the case of IPV4). The people who are truly interested in speeding up IPV6 adoption should do their best to shut up the internet hippies who constantly rant and rave about how NAT is evil. Don't let the cause get distracted by that unrelated issue. Focus on the core issue. You are being over-simplistic. Lack of IPv4 address space *caused* NAT to happen, the two are inextricably intertwined. Even worse, people now have NAT conflated with all sorts of other things. Like for example NAT and security. NAT is the context of an IPv6 discussion is *very* relevant, it's one of the points you have to raise to illustrate what bits inside people's heads needs to be identified and changed. Until you change the content of people's heads, IPv6 is just not going to happen. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: LO 4.0 playing media with gstreamer-1.0.5 ?
Hello! On Sun, 10 Mar 2013 20:09:00 -0500 Dale rdalek1...@gmail.com wrote: walt wrote: No, my 4.0.1.2 doesn't play your presentation. It displays a light brown rectangle and nothing else. I uploaded your odp to google docs and tried to play it but I've never tried that before so I'm probably doing something wrong. More informed opinions are welcome, of course :) That was what I got to. I thought maybe it was just me so I didn't post. Guess it was not just me. Dale Thank you for testing! That is exactly the problem. I am able to play this presentation in LibreOffice-3.6 on Gentoo and in LibreOffice-3.5 on Debian. I also tried to play it in LibreOffice-4 for Windows, and it went just fine. So, the problem seems to be related to either Gentoo libraries (for example, ffmpeg -- libav transition) or with my current configuration. Any other opinions/tests/suggestions? Thank you! Vladimir - v...@ukr.net
[gentoo-user] Gnome 3.6.2 fallback - panel.
Hello, I'm having a problem with blank spaces between buttons and their size (too big) in notification bar (gnome 3.6.2 fallback mode). In dconf their size is 'small' . I've already tried to modify the: .config/gtk-3.0/settings.ini and added: [Settings] gtk-fallback-icon-theme = gnome gtk-icon-sizes = panel-menu=16,16;gtk-large-toolbar=16,16 But, I dont't know why it enlarges icons size. Screenshot: http://imageshack.us/photo/my-images/705/panelkj.png Thanks for your help.
Re: [gentoo-user] A question concerning graphics...
Am 11.03.2013 00:07, schrieb Alecks Gates: On Sun, Mar 10, 2013 at 5:53 PM, Michael Hampicke gentoo-u...@hadt.biz wrote: Am 10.03.2013 21:48, schrieb Alecks Gates: On Sun, Mar 10, 2013 at 7:28 AM, Michael Hampicke gentoo-u...@hadt.biz wrote: [...] I use the ati-drivers package, and I'd say there are pretty solid now. I first started using ati-drivers with my HD2600 card card - as the kernel drivers did not support the power saving mechanisms of the card. No power saving on the HD2600 meant just when idling: 60 degree C and a power usage of over 30 watts more then when using the kernel driver. Not to mention the noise of the fan. When I bought my new HD 7770 card last year, it was not supported by the kernel, so I sticked with the ati-drivers. Everythings works as it's supposed to. Dual screen setup with different solutions, power saving when idling, 3D power when you need it (steam games), opencl works fine too. I just bought a 7770 myself, and have been interested in getting a dual monitor setup with ati-drivers. What steps do I have to take? Just fire up the AMD catalyst control center, configure to your liking, that's it pretty much. I do run gnome 3.6 - but configuring dual monitors only with gnome (via system settings) was not possible. I noticed the same about Gnome. I did try it in AMD Catalyst but was unsuccessful. Do I need xinerama support? I don't have xinerama enabled on any of my packages. Here is the xorg.conf which AMD CC generated, maybe it helps: Section ServerLayout Identifier aticonfig Layout Screen 0 aticonfig-Screen[0]-0 0 0 EndSection Section Module EndSection Section InputClass Identifier evdev keyboard catchall Driver evdev MatchDevicePath /dev/input/event* MatchIsKeyboard yes Option XkbLayout de EndSection Section Monitor Identifier aticonfig-Monitor[0]-0 Option VendorName ATI Proprietary Driver Option ModelName Generic Autodetecting Monitor Option DPMS true EndSection Section Monitor Identifier 0-DFP9 Option VendorName ATI Proprietary Driver Option ModelName Generic Autodetecting Monitor Option DPMS true Option PreferredMode 1920x1080 Option TargetRefresh 60 Option Position 0 0 Option Rotate normal Option Disable false EndSection Section Monitor Identifier 0-CRT1 Option VendorName ATI Proprietary Driver Option ModelName Generic Autodetecting Monitor Option DPMS true Option PreferredMode 1280x1024 Option TargetRefresh 60 Option Position 1920 0 Option Rotate normal Option Disable false EndSection Section Device Identifier aticonfig-Device[0]-0 Driver fglrx Option Monitor-DFP9 0-DFP9 Option Monitor-CRT1 0-CRT1 BusID PCI:1:0:0 EndSection Section Device Identifier amdcccle-Device[1]-1 Driver fglrx Option Monitor-CRT1 0-CRT1 BusID PCI:1:0:0 Screen 1 EndSection Section Screen Identifier aticonfig-Screen[0]-0 Device aticonfig-Device[0]-0 DefaultDepth 24 SubSection Display Viewport 0 0 Virtual 3200 3200 Depth 24 EndSubSection EndSection Section Screen Identifier amdcccle-Screen[1]-1 Device amdcccle-Device[1]-1 DefaultDepth 24 SubSection Display Viewport 0 0 Depth 24 EndSubSection EndSection
Re: [gentoo-user] Re: module-init-tools : masked opponent : SOLVED
130309 Philip Webb wrote: 130309 »Q« wrote: 130309 Philip Webb purs...@ca.inter.net wrote: Doing my usual Saturday system update, I saw a prominent msg telling me that 'module-init-tools' has been masked to use 'kmod' or 'modutils' -- the msgs vary -- to replace it. When I did so (both), Nvidia wouldn't start, even after remerging it. Back with 'module-init-tools' -- now in 'package.unmask' -- all is well. Does anyone know what's going on ? -- did I miss a 'news' item ? When you built kmod, was it with the tools flag enabled ? The virtual requires it. Thanks : Kmod needs USE=tools Udev + virtual need USE=kmod . With those in package.use the problem is solved. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] kernel 3.8 and external drivers
On 11.03.2013 03:05, Daniel Wagener wrote: On Sun, 10 Mar 2013 21:53:42 +0100 Volker Armin Hemmann volkerar...@googlemail.com wrote: Am 10.03.2013 19:28, schrieb Daniel Wagener: Hello, I ran into some trouble about an hour ago… My workstation has an onboard Realtek Ethernet which only works with the r8168 driver. Unfortunately, this driver is not in the kernel, but available to be compiled as a kernel module. (I guess because of som patents) That worked for quite some time, until i thought hey, you got an hour of time, your workstation is still on 3.7.4, why don't you just upgrade it to 3.8.2? So I did, only to find out that Linus and his friends changed the way drivers are initialized… (__devinit got unsupported for example) Of course, the guys who wrote that r8169 have not changed their code yet. tl;dr: My network is broken since 3.8.0. So for an immediate fix I am emerging 3.7.10 (since emerge --depclean deleted the Kernel source when it found the source fo 3.7.8 which got removed as soon as 3.8.2 was emerged…) to get it working again. For the long run im thinking of buying a PCI(e) card with Kernel support. Or maybe, if I find some time I will fix the driver myself. My question now is: Who should I talk to so something like this does not happen again? A certain gentoo dev, who could issue warnings on emerging kernels, something like excerpts from the changelog? Myself, because I missed what I described above? The devs of the r8169? Linus co for breaking things? Myself bcause I forgot something else? Realtek? Or someone completely different? so, you are using a superfluous external driver. Despite the fact that external drivers are prone to breaking you insist on using the latest kernel, instead using the latest kernel of one of the stable kernel series like 3.4. To add insult to injury you remove kernels after installing instead of after testing. well… I guess that sums it up… :( sorry for breaking in, but... (to Volker Armin Hemmann) 1. If this driver is superfluous as you say, then why does it ever exist in portage? 2. Since it does exist, then probably it would be much nicer to user to show him a notice when he (user) tries to compile it on a kernel which has native support for the device, or moreover an unsupported kernel installed, than blame user for that? 3. Why does the ebuild *not* check for supported kernel version or breaking APIs/ABIs? 4. How and why would you expect to force all users to grep thru kernel src in search for a driver they might need, especially when the portage explicitly lists this driver? Also sometimes kernel drivers' description is not quite consistent and it is not easy to figure out whether it supports exactly yours card/chip/device, or moreover find it by grep. 5. After all, linux and gentoo in particular are *not* developer-only-oriented systems, and it is up to maintainers or whomever to make them more user-friendly. Yes, it is not fair of a user to blame someone for breaking APIs etc. but neither it is fair to blame the user for not knowing everything as I bet nobody knows everything about linux kernel. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] IO latency issues
maybe it will be fixed in kernel 3.9 http://www.phoronix.com/scan.php?page=news_itempx=MTMxNzA 2013/3/11 Florian Philipp li...@binarywings.net Am 10.03.2013 13:48, schrieb Florian Philipp: Am 10.03.2013 00:53, schrieb cosmoslx lin: 2013/3/10 Volker Armin Hemmann volkerar...@googlemail.com mailto:volkerar...@googlemail.com Am 09.03.2013 19:15, schrieb Florian Philipp: Hi list! Whenever I do sequential IO for a long stretch of time (e.g. md5summing 40 GB), I'm experiencing high load (ca. 6 on a 4 CPU system) and temporary freezes of most applications. For example, switching between tabs in konsole sometimes takes more than 2 seconds. [...] congratulation. You hit 'the bug'. Been around for ages, but for magical reasons kernel dev are unable to see or unable to do something about it. If you are using a vanilla kernel, posting on lkml might be the right thing to do. I have try the BFQ patch outside of the kernel mainline, it works well. Maybe you would like to see: http://algo.ing.unimo.it/people/paolo/disk_sched/ Thanks. I'll try pf-sources which should to include that patch set. Regards, Florian Philipp pf-sources (only BFQ enabled, not BFS) helped somewhat. kswapd still likes to keep one CPU busy when IO is happening but I suspect cleancache to be the culprit for that. I'll test without it later. Regards, Florian Philipp -- Best regards! Yu-yu Lin(林育宇) The Guangdong Key Laboratory of Information Security Technology (IST), School of Information Science and Technology, Sun Yat-sen (Zhongshan) University (中山大学), Guangzhou,P.R.China. Email: cosmo...@gmail.com cosmo...@gmail.com
Re: [gentoo-user] kernel 3.8 and external drivers
Am 11.03.2013 14:00, schrieb Yuri K. Shatroff: On 11.03.2013 03:05, Daniel Wagener wrote: On Sun, 10 Mar 2013 21:53:42 +0100 Volker Armin Hemmann volkerar...@googlemail.com wrote: Am 10.03.2013 19:28, schrieb Daniel Wagener: Hello, I ran into some trouble about an hour ago… My workstation has an onboard Realtek Ethernet which only works with the r8168 driver. Unfortunately, this driver is not in the kernel, but available to be compiled as a kernel module. (I guess because of som patents) That worked for quite some time, until i thought hey, you got an hour of time, your workstation is still on 3.7.4, why don't you just upgrade it to 3.8.2? So I did, only to find out that Linus and his friends changed the way drivers are initialized… (__devinit got unsupported for example) Of course, the guys who wrote that r8169 have not changed their code yet. tl;dr: My network is broken since 3.8.0. So for an immediate fix I am emerging 3.7.10 (since emerge --depclean deleted the Kernel source when it found the source fo 3.7.8 which got removed as soon as 3.8.2 was emerged…) to get it working again. For the long run im thinking of buying a PCI(e) card with Kernel support. Or maybe, if I find some time I will fix the driver myself. My question now is: Who should I talk to so something like this does not happen again? A certain gentoo dev, who could issue warnings on emerging kernels, something like excerpts from the changelog? Myself, because I missed what I described above? The devs of the r8169? Linus co for breaking things? Myself bcause I forgot something else? Realtek? Or someone completely different? so, you are using a superfluous external driver. Despite the fact that external drivers are prone to breaking you insist on using the latest kernel, instead using the latest kernel of one of the stable kernel series like 3.4. To add insult to injury you remove kernels after installing instead of after testing. well… I guess that sums it up… :( sorry for breaking in, but... (to Volker Armin Hemmann) 1. If this driver is superfluous as you say, then why does it ever exist in portage? because it exists? gnome is there too. Or systemd AND openrc. mrxvt, rxvt AND urxvt. 2. Since it does exist, then probably it would be much nicer to user to show him a notice when he (user) tries to compile it on a kernel which has native support for the device, or moreover an unsupported kernel installed, than blame user for that? no, this is gentoo. You are supposed to do your homework. No training wheels. 3. Why does the ebuild *not* check for supported kernel version or breaking APIs/ABIs? why should it? See above. You can't know if in the future something might change. 4. How and why would you expect to force all users to grep thru kernel src in search for a driver they might need, especially when the portage explicitly lists this driver? Also sometimes kernel drivers' description is not quite consistent and it is not easy to figure out whether it supports exactly yours card/chip/device, or moreover find it by grep. All kernel source? grep? Nope. Just reading a bit of help text. Maybe using google. Doing it once. Then you have a working setup you can use for the rest of eternity (or the next couple of years...) 5. After all, linux and gentoo in particular are *not* developer-only-oriented systems, and it is up to maintainers or whomever to make them more user-friendly. Yes, it is not fair of a user to blame someone for breaking APIs etc. but neither it is fair to blame the user for not knowing everything as I bet nobody knows everything about linux kernel. oh, so gentoo is for ubuntu users? Well, why not use ubuntu in the first place? But I feel generous right now. You might have a point there. That does not invalidate the 'remove kernels before testing' criticism from the list nor does it solve the 'insisting to use the latest kernel release instead of stable series' problem.
Re: [gentoo-user] kernel 3.8 and external drivers
Am 11.03.2013 00:05, schrieb Daniel Wagener: On Sun, 10 Mar 2013 21:53:42 +0100 Volker Armin Hemmann volkerar...@googlemail.com wrote: Am 10.03.2013 19:28, schrieb Daniel Wagener: Hello, I ran into some trouble about an hour ago… My workstation has an onboard Realtek Ethernet which only works with the r8168 driver. Unfortunately, this driver is not in the kernel, but available to be compiled as a kernel module. (I guess because of som patents) That worked for quite some time, until i thought hey, you got an hour of time, your workstation is still on 3.7.4, why don't you just upgrade it to 3.8.2? So I did, only to find out that Linus and his friends changed the way drivers are initialized… (__devinit got unsupported for example) Of course, the guys who wrote that r8169 have not changed their code yet. tl;dr: My network is broken since 3.8.0. So for an immediate fix I am emerging 3.7.10 (since emerge --depclean deleted the Kernel source when it found the source fo 3.7.8 which got removed as soon as 3.8.2 was emerged…) to get it working again. For the long run im thinking of buying a PCI(e) card with Kernel support. Or maybe, if I find some time I will fix the driver myself. My question now is: Who should I talk to so something like this does not happen again? A certain gentoo dev, who could issue warnings on emerging kernels, something like excerpts from the changelog? Myself, because I missed what I described above? The devs of the r8169? Linus co for breaking things? Myself bcause I forgot something else? Realtek? Or someone completely different? so, you are using a superfluous external driver. Despite the fact that external drivers are prone to breaking you insist on using the latest kernel, instead using the latest kernel of one of the stable kernel series like 3.4. To add insult to injury you remove kernels after installing instead of after testing. well… I guess that sums it up… :( I hope so. But not all is lost. You learnt a lesson, next time someone does something like that you can act like the resident asshole and I get a couple of minutes off. Everybody wins. Especially me.
Re: [gentoo-user] Re: kernel 3.8 and external drivers
On 03/11/13 01:34, Nikos Chantziaras wrote: [snip] config R8169 tristate Realtek 8169 gigabit ethernet support Say Y here if you have a Realtek 8169 PCI Gigabit Ethernet adapter. To compile this driver as a module, choose M here: the module will be called r8169. This is recommended. oh great, so I actually mixed it up… the 8169 is in the Kernel yes, but what i need is the 8168 The in-kernel drive (supposedly) supports 8168: r8169.c: RealTek 8169/8168/8101 ethernet driver. Thanks for encouraging me, the in-kernel driver actually works. Note that you also need to emerge sys-kernel/linux-firmware. The driver will work without it, but the ethernet connection can hang after an hour or so. You can verify whether you need to install the firmware or not by inspecting the kernel log: dmesg | grep -i firmware This should show the kernel trying to load the firmware for your R8168 chip but failing. I had my share of problems with recent kernels and Realtek 8168 so I went and bought and internal network card: Intel Corporation 82574L Gigabit Network Connection card. I did know that I'm suppose to install sys-kernel/linux-firmware I just did (just in case) but running: dmesg | grep -i firmware doesn't show that kernel is trying to load anything. -- Joseph
[gentoo-user] USB Tethering Android
Hi, I'm trying to tether 3G from my Xperia S and Nexus 4 via USB, but the interface doesn't show up (earlier I used to get usb0 after enabling tethering). I have compiled all related drivers : cdc_acm, cdc_ether, cdc_ncm as modules. I tried inserting modules manually and then plugging the phone, but interface still doesn't appear. What am I missing?
[gentoo-user] sys-devel/bc required for kernel compile?
My wife and I have identical Dell XPS 13 laptops. I have the config on both as close as possible. We use identical kernel config files, but I can compile git-sources-3.9-rc1 without installing sys-devel/bc and it looks like she can not. Does anyone know why this would happen? BC kernel/timeconst.h /bin/sh: bc: command not found make[1]: *** [kernel/timeconst.h] Error 127 make: *** [kernel] Error 2 - Grant
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On Mon, Mar 11, 2013 at 10:22:39AM +0200, Alan McKinnon wrote You are being over-simplistic. Lack of IPv4 address space *caused* NAT to happen, the two are inextricably intertwined. Agreed. But we shouldn't be pointing out that NAT has partially solved the problem, and giving people false hope that NAT will solve the shortage problem forever. We should be pounding away on the fact that we're running out of IP addresses... period... end of story. If people ask about NAT, then mention that the undersupply will be so bad that even NAT won't help. Even worse, people now have NAT conflated with all sorts of other things. Like for example NAT and security. That's why I wwant to avoid that propaganda battle. It's been lost already. Deal with it. Don't waste time and effort on it. Put your effort into pounding away on a simple issue that people do understand... we're running out of IP addresses. NAT is the context of an IPv6 discussion is *very* relevant, it's one of the points you have to raise to illustrate what bits inside people's heads needs to be identified and changed. Until you change the content of people's heads, IPv6 is just not going to happen. I disagree with you there. IPV6 adoption will be driven by shortage of addresses, which people can understand. It will not be accomplished by sermons about the evils of NAT whilst people's eyes glaze over. A preachment, dear friends, you are about to receive, is on John Barleycorn, Nicotine, and the Temptations of NAT. And if it comes down to it, I'd much rather have IPV6 with IPV6 NAT being available, rather than no IPV6. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
Don't waste time and effort on it. Put your effort into pounding away on a simple issue that people do understand... we're running out of IP addresses. We have run out of unallocated ones, there are still loads of unused ones and even more due to global NAT, and even some being released. It is true eventually it will be an absolute problem but hopefully by then we will have a cleaner ipv7. Lets hope ISPs get smarter as recently they have gone downhill with all their *DANGEROUS* as cited by snort.org and compulsory layer 7 sifting. Until ipv6 is revised I can't see a day when there will be no ipv4. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On 03/09/2013 07:53 AM, Kevin Chadwick wrote: There is no reason to believe that IPv6 will result in an increased use of IPsec. Bull. The biggest barrier to IPsec use has been NAT! If an intermediate router has to rewrite the packet to change the apparent source and/or destination addresses, then the cryptographic signature will show it, and the packet will be correctly identified as having been tampered with! http://marc.info/?l=openbsd-miscm=135325641430178w=2 It's hardly difficult to get around that now is it. Sure, you can use an IP-in-IP tunnel...but that's retarded. IPSec was designed from the beginning to allow you to do things like sign your IP header and encrypt everything else (meaning your UDP, TCP, SCTP or what have you). Setting up a tunnel just so your IP header can be signed wastes another 40 bytes for every non-fragmented packet. Ask someone trying to use data in a cellular context how valuable that 40 bytes can be. You are wrong the biggest barrier is that it is not desirable to do this as there are many reasons for firewalls to inspect incoming packets. I don't agree with things like central virus scanning especially by damn ISPs using crappy Huawei hardware, deep inspection traffic shaping rather than pure bandwidth usage tracking or active IDS myself but I do agree with scrubbing packets. It's not the transit network's job to scrub packets. Do your scrubbing at the VPN endpoint, where the IPSec packets are unwrapped. Trusting the transit network to scrub packets is antithetical to the idea of using security measures to avoid MITM and traffic sniffing attacks in the first place! I never said it was. I was more thinking of IPSEC relaying which would be analogous to a VPN end point but without losing the end-end, neither are desirable, NAT has little to do with the lack of IPSEC deployment. What do you gain considering the increased resources, pointlessly increasing chances of cryptanalysis and pointlessly increasing the chances of exploitation due to the fact that the more complex IPSEC itself can have bugs like Openssl does, not to mention amplifying DDOS without the attacker doing anything, which is the biggest and more of a threat than ever, or are you going to stop using the internet. When ipv4 can utilise encryption without limitations including IPSEC but more appropriately like ssh just fine when needed you see it is simply not desirable and a panacea that will not happen. You are simply in a bubble as the IETF were. With IPsec, NAT is unnecessary. (You can still use it if you need it...but please try to avoid it!) Actually it is no problem at all and is far better than some of the rubbish ipv6 encourages client apps to do. (See the links I sent in the other mail) Please read the links before you send them, and make specific references to the content you want people to look at. I've read and responded to the links you've offered (which were links to archived messages on mailing lists, and the messages were opinion pieces with little (if any) technical material.) Re DNS support for IPv6 Increased size of DNS responses due to larger addresses might be exploited for DDos attacks That's not even significant. Have you looked at the size of DNS responses? The increased size of the address pales in comparison to the amount of other data already stuffed into the packet. It's been ages since I looked at that link and longer addresses would certainly be needed anyway but certainly with DNSSEC again concocted by costly unthoughtful and unengaging groups who chose to ignore DJB and enable amplification attacks. What from DJB did they ignore? I honestly don't know what you're talking about. They completely ignored dnscurve.org or that RSA768 was not strong enough to be a good choice and ECDSA should be looked at and most importantly the DOS amplification (we are talking years ago). I even had a discussion with a dns caching tools (that I do like a lot) author who completely dismissed the potential of RSA being broken for years and years. Guess what's come to light since. His latest on the DNS security mess http://cr.yp.to/talks/2013.02.07/slides.pdf I've never before in my life seen someone animate slideshow transitions and save off intermediate frames as individual PDF pages. That was painful. Yeah, xpdf worked well though. I actually couldn't find the link and looked it up and thought it was just an update of 2012 as it had the same title and only got around to reading it about an hour later. So, I read what was discussed there. First, he describes failings of HTTPSEC. I don't have any problem with what he's talking about there, honestly; it makes a reasonable amount of sense, considering intermediate caching servers aren't very common for HTTP traffic, and HTTPS traffic makes intermediate caching impossible. (unless
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
No, there was simply no useful result that came up. Incidentally, both links you provide *did* come up...but I dismissed them because I couldn't imagine anyone using them as a reference except in trying to deride Henning Brauer. http://marc.info/?l=openbsd-miscm=129666298029771w=2 He goes from advocating NAT444 to a spew of pejoratives about something. NAT444 is one of the nastiest, user-disempowering things to hit the Internet to date. The rest of this email is him bitching about having to parse CIDR notation. How disengenuous. He certainly doesn't. Did you miss the sarcasm. The only reason he advocates is because others using it allow him to keep running ipv4 pure networks. After that I'm sure you can forgive me if I note him to have absolutely no reason to be biased and give him a bit more credit and take his experience of writing one of the best and widely used interrupt driven firewalls and so code to deal with ipv6, helping get the netqmail patch sorted and runs his own decent sized network over yours who I am sure is genuine but could well be partial to ipv6 because as you say you teach setting up ipv6 networks. http://marc.info/?l=openbsd-miscm=124536321827774w=2 http://marc.info/?l=openbsd-miscm=135325826302392w=2 This email has absolutely no technical content whatsoever. Did you not follow the threads? I couldn't find the juicier threads about client troubles due to added complexity but here's some relevent ones and many by very competent devs. (and if I'm honest who tend to shadow every other list I've come across so far as long as you are not timid and can take a hit, though Gentoo is up there). http://marc.info/?l=openbsd-miscm=128822984018595w=2 http://marc.info/?l=openbsd-miscm=135325736302228w=2 http://marc.info/?l=openbsd-miscm=128825496411711w=2 http://marc.info/?l=openbsd-miscm=129665675320651w=2 http://marc.info/?l=openbsd-miscm=135111069427240w=2 http://marc.info/?l=openbsd-miscm=135110983026959w=2 http://marc.info/?l=openbsd-miscm=135110833526455w=2 http://marc.info/?l=openbsd-miscm=135110805826344w=2 http://marc.info/?l=openbsd-miscm=135110703125929w=2 http://marc.info/?l=openbsd-miscm=135110533625263w=2 http://marc.info/?l=openbsd-miscm=124537193506202w=2 -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [Bulk] Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
NAT behind a home router is bad, too. For IPv4, it's only necessary because there aren't enough IPv4 addresses to let everyone have a unique one. The best real reason for moving to IPV6 is address space (or lack thereof, in the case of IPV4). The people who are truly interested in speeding up IPV6 adoption should do their best to shut up the internet hippies who constantly rant and rave about how NAT is evil. Don't let the cause get distracted by that unrelated issue. Focus on the core issue. I completely agree divide and conquer tactics. You are being over-simplistic. Lack of IPv4 address space *caused* NAT to happen, the two are inextricably intertwined. Even worse, people now have NAT conflated with all sorts of other things. Like for example NAT and security. NAT was around way earlier and may I state again also that I have externally facing servers and games machines behind NAT. So are you saying that you think it is good for every machine to be in a DMZ, few chosen ones yes. I disagree completely as I do with the usefullness of push-email. NAT is the context of an IPv6 discussion is *very* relevant, it's one of the points you have to raise to illustrate what bits inside people's heads needs to be identified and changed. Until you change the content of people's heads, IPv6 is just not going to happen. NAT has more uses than those two, NAT type of functionality is apparently desired by some ipv6 networks to allow easier ISP migration. It's true NAT distracts from the bad points of ipv6 and which is the only part irrelevent for ipv4 modded to work with a larger address space (ipv5). I wonder if this is an example of how these technologies can get so convoluted? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On 12/03/2013 00:45, Walter Dnes wrote: NAT is the context of an IPv6 discussion is *very* relevant, it's one of the points you have to raise to illustrate what bits inside people's heads needs to be identified and changed. Until you change the content of people's heads, IPv6 is just not going to happen. I disagree with you there. IPV6 adoption will be driven by shortage of addresses, which people can understand. It will not be accomplished by sermons about the evils of NAT whilst people's eyes glaze over. A preachment, dear friends, you are about to receive, is on John Barleycorn, Nicotine, and the Temptations of NAT. And if it comes down to it, I'd much rather have IPV6 with IPV6 NAT being available, rather than no IPV6. Hmmm, I'm still not convinced. NAT (plus a whole boat load of other crap we've accumulated over the years, NAT merely being the well-known poster-boy) is so ingrained in people's heads it is now one of those things that we have to deal with. Ignoring it (and the other crap too) is not going to change that it really is up at the top of people's thought process. When I say people I of course mean people I interact with. I don't claim to speak for all persons who deal with the internet somehow. Yes, we should and must pound away that IPv4 is a limited resource and it's close to being used up. But we still have to deal with the other objections that rightly or wrongly get dumped on the table too. Why do I think we must deal with these other issues rather than concentrate on the major one? Because the other guy won't let it go and won't really engage a discussion about IPv6 for real as he's sitting with all these other objections uppermost in his mind. Chief amongst them is the knowledge that he will have to redesign his entire network from scratch (we all know that IPv6 is not a drop-in replacement for IPv4) and the fear that somehow he has to keep business going and the lights on while doing it. That scares people. Well, that's my experience anyway. Some days it feels like getting Kuthrapauli to talk to women. We know all he needs to do is talk to them. He can't get past the thought that he has to find a glass of wine first... -- Alan McKinnon Systems Engineer^W Technician Infrastructure Services Internet Solutions +27 11 575 7585 -- Alan McKinnon alan.mckin...@gmail.com
Re: [Bulk] Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On 12/03/2013 01:31, Kevin Chadwick wrote: NAT behind a home router is bad, too. For IPv4, it's only necessary because there aren't enough IPv4 addresses to let everyone have a unique one. The best real reason for moving to IPV6 is address space (or lack thereof, in the case of IPV4). The people who are truly interested in speeding up IPV6 adoption should do their best to shut up the internet hippies who constantly rant and rave about how NAT is evil. Don't let the cause get distracted by that unrelated issue. Focus on the core issue. I completely agree divide and conquer tactics. You are being over-simplistic. Lack of IPv4 address space *caused* NAT to happen, the two are inextricably intertwined. Even worse, people now have NAT conflated with all sorts of other things. Like for example NAT and security. NAT was around way earlier and may I state again also that I have externally facing servers and games machines behind NAT. I fail to see your point, and you have answered a question I did not ask. I too have that same circumstance, as likely does every one else here who works in networks for a living. So what? We have that because the environment gives us little choice. It doesn't make it good, bad, desirable or undesirable. it simply is and we have few realistic alternative choices. So are you saying that you think it is good for every machine to be in a DMZ, few chosen ones yes. That's also a question I did not ask, and one I do not care to debate. I disagree completely as I do with the usefullness of push-email. NAT is the context of an IPv6 discussion is *very* relevant, it's one of the points you have to raise to illustrate what bits inside people's heads needs to be identified and changed. Until you change the content of people's heads, IPv6 is just not going to happen. NAT has more uses than those two, NAT type of functionality is apparently desired by some ipv6 networks to allow easier ISP migration. You are going to have to back that up with some reasoned arguments. The only reason I can see why some might desire that is their reluctance to give up on old habits. happy to be shown to be wrong though. It's true NAT distracts from the bad points of ipv6 and which is the only part irrelevent for ipv4 modded to work with a larger address space (ipv5). I wonder if this is an example of how these technologies can get so convoluted? McKinnon's Law of Human Implementation of Solutions: Any sufficiently large and representative group of humans when faced with making new choices to solve old problems, will always decide on the most complex convoluted solution that can be implemented soonest. Relevant? I dunno. But it sure sounds good. -- Alan McKinnon alan.mckin...@gmail.com
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On 03/11/2013 06:45 PM, Walter Dnes wrote: On Mon, Mar 11, 2013 at 10:22:39AM +0200, Alan McKinnon wrote You are being over-simplistic. Lack of IPv4 address space *caused* NAT to happen, the two are inextricably intertwined. Agreed. But we shouldn't be pointing out that NAT has partially solved the problem, and giving people false hope that NAT will solve the shortage problem forever. The truth of the matter is that it kinda does, for most of these people. For most of those for whom it doesn't, there are (and will be) plenty of third-party services looking to allow them to throw money at the problem for an opaque solution. (It's like sausage; it works, it's nutritious, it tastes great...but YMMV if you see how it's made.) For small businesses for whom the IP shortage already crowded out of traditional network management, the Cloud was born. Large businesses make a mess of their networks, but hobble along. So workarounds were developed. What NAT has *done*, though, is force a stratification and classification of services, making vast swaths of network applications impossible or incredibly niche. If one doesn't acknowledge the truth of the matter, one gets nailed to the wall with it when someone smart enough to consider it brings it up as a counterpoint. We should be pounding away on the fact that we're running out of IP addresses... period... end of story. If people ask about NAT, then mention that the undersupply will be so bad that even NAT won't help. In my presentations, I've stopped bothering to wait for people to ask about NAT, because it starts off in their minds from nearly the beginning--and until they get that question answered, most of what I say washes past them as ancillary and not as important as the question pressing on their minds. Even worse, people now have NAT conflated with all sorts of other things. Like for example NAT and security. That's why I wwant to avoid that propaganda battle. It's been lost already. Deal with it. Don't waste time and effort on it. Put your effort into pounding away on a simple issue that people do understand... we're running out of IP addresses. That's the thing. We're running out, we've *run* out. Past tense. I keep pointing to my friend whose ISP hands him RFC1918 addresses as an example, because that's just the way things are. I can also point to mobile carriers--most local network regions hand out RFC1918 addresses for IPv4, which means you're double-NATting if you use your phone to share your network connection. At one point a couple *years* ago, my T-Mobile phone told me it had what I thought was a public IPv4 address...but it turned out to be an address owned by some security-related branch of the British government who didn't advertise routes, and so T-Mobile was able to use British government netblocks internally as a kind of extension to RFC1918 space. Around the same time, a friend's Verizon phone in the area had a legit public IPv4 address if and only if he was sharing his network connection at that moment...otherwise Verizon would switch him back to an RFC1918 address. So, I say again, we've run out of IPv4 addresses. Past tense. What's left after that is to explain why most of the people you'll ever talk to don't feel pain from it, and explain to them why their anaesthetic is keeping them from realizing their network is paraplegic. NAT is the context of an IPv6 discussion is *very* relevant, it's one of the points you have to raise to illustrate what bits inside people's heads needs to be identified and changed. Until you change the content of people's heads, IPv6 is just not going to happen. I disagree with you there. IPV6 adoption will be driven by shortage of addresses, which people can understand. I agree. The problem is that the IPv4 network as it exists today is highly optimized for asymmetric client-server topologies, and the pains and breakages will largely go unnoticed or unattributed due to the layers upon layers of abstractions, band-aids and jerry-rigging. As a consequence, it's necessary to help people understand what they're missing. It will not be accomplished by sermons about the evils of NAT whilst people's eyes glaze over. A preachment, dear friends, you are about to receive, is on John Barleycorn, Nicotine, and the Temptations of NAT. I don't tend to encounter peoples' eyes glazing over. All my presentations are in QA format. There's one guy who's gone to four of them, because, as he told me, it's different every time. And if it comes down to it, I'd much rather have IPV6 with IPV6 NAT being available, rather than no IPV6. Sure. I think IPv6 NAT has its place, but I personally feel it should be done above layer 3, in application-layer gateways. If you're in a scenario where you need IPv6 NAT, you're almost certainly in a scenario where you would benefit from the additional features an ALG would give you. signature.asc Description: OpenPGP
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On 03/11/2013 06:34 PM, Kevin Chadwick wrote: On 03/09/2013 07:53 AM, Kevin Chadwick wrote: There is no reason to believe that IPv6 will result in an increased use of IPsec. Bull. The biggest barrier to IPsec use has been NAT! If an intermediate router has to rewrite the packet to change the apparent source and/or destination addresses, then the cryptographic signature will show it, and the packet will be correctly identified as having been tampered with! http://marc.info/?l=openbsd-miscm=135325641430178w=2 I believe you've misunderstood what Brauer is saying there. NAT needs to process every packets opposed to the !NAT case, where a router doesn't have to process every packet. rrright. Here, when Brauer is talking about processing, he's not talking about tampering with (modifying) packets, he's talking about inspecting them as part of connection state and for other things. This is absolutely distinct from *modifying* the packet, which is what IPsec is intended to detect. I also wouldn't count 'dropping' packets as modification, as: A) an intermediate firewall isn't likely to allow any packet of a stream through to begin with if it's going to block any packet in the stream at all. B) Handling of dropped packets is the responsibility of the transport layer. UDP is supposed to handle it in stride. TCP is supposed to notice and retry. It's hardly difficult to get around that now is it. Sure, you can use an IP-in-IP tunnel...but that's retarded. IPSec was designed from the beginning to allow you to do things like sign your IP header and encrypt everything else (meaning your UDP, TCP, SCTP or what have you). Setting up a tunnel just so your IP header can be signed wastes another 40 bytes for every non-fragmented packet. Ask someone trying to use data in a cellular context how valuable that 40 bytes can be. You are wrong the biggest barrier is that it is not desirable to do this as there are many reasons for firewalls to inspect incoming packets. I don't agree with things like central virus scanning especially by damn ISPs using crappy Huawei hardware, deep inspection traffic shaping rather than pure bandwidth usage tracking or active IDS myself but I do agree with scrubbing packets. It's not the transit network's job to scrub packets. Do your scrubbing at the VPN endpoint, where the IPSec packets are unwrapped. Trusting the transit network to scrub packets is antithetical to the idea of using security measures to avoid MITM and traffic sniffing attacks in the first place! I never said it was. I was more thinking of IPSEC relaying which would be analogous to a VPN end point but without losing the end-end, neither are desirable, Please, explain to me what the heck you mean, then? When you say You are wrong the biggest barrier is that it is not desirable to do this as there are many reasons for firewalls to inspect incoming packets. I can't possibly understand what you're talking about except with the context you've given me. The only other thing I can take from what you're saying up to this point is that you believe VPNs are bad, which I find, well, laughable. NAT has little to do with the lack of IPSEC deployment. You keep saying this, but saying a thing doesn't make it understood; you have to explain why. What do you gain considering the increased resources, You mean the bandwidth overhead of the ESP and/or AH headers? As opposed to, what, TLS? GRE? IP-in-TLS-in-IP? Let me have a clean, cheap TCP-on-ESP-on-IP stack for my campus-to-campus connections! pointlessly increasing chances of cryptanalysis and pointlessly increasing the chances of exploitation due to the fact that the more complex IPSEC itself can have bugs like Openssl does, If I read your argument correctly, you would view encryption in general as harmful? not to mention amplifying DDOS without the attacker doing anything, which is the biggest and more of a threat than ever, One of my servers is currently undergoing a SYN flood. I'm well aware that the Internet is a dangerous place. Honestly, if someone wants to DDOS you, the increased amplification factor of DNSSEC isn't going to be the deciding factor of whether your server stays up or goes down. or are you going to stop using the internet. Use hyperbole much? When ipv4 can utilise encryption without limitations including IPSEC but more appropriately like ssh just fine when needed you see it is simply not desirable and a panacea that will not happen. You are simply in a bubble as the IETF were. For the purposes of tunnels, I've used IPsec on IPv4, SSH and TLS. Quite frankly? IPsec on IPv6 is the least painful option of all of these. IPsec on IPv4 is frustrating because the VPN clients are poorly implemented, and you *must* use TCP/UDP-in-ESP/AH-in-(optional TCP or UDP in)-IP, or you're not going to get through NAT without getting the network administrator to
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On Mon, Mar 11, 2013 at 11:39:35PM +, Kevin Chadwick wrote Don't waste time and effort on it. Put your effort into pounding away on a simple issue that people do understand... we're running out of IP addresses. We have run out of unallocated ones, there are still loads of unused ones... and even some being released. And they'll run out rather quickly at the rate they're being assigned. There are approximately 3.7 billion usable IPV4 addresses. Soon, that will be one for every 2 people on this planet. And don't forget the people who have an account at home, a smartphone with web access, and an internet-connected desktop at work. Conservation of IP addresses will buy us a couple more years, but that's it. and even more due to global NAT... In another message you said... ...and may I state again also that I have externally facing servers and games machines behind NAT. Yes, that works if *YOU* have at least 1 public IP address and *YOU* control port-forwarding. But it won't work behind carrier-level NAT. It is true eventually it will be an absolute problem but hopefully by then we will have a cleaner ipv7. It won't happen. It's too late to start from scratch, and the IPV6 rollout has already begun. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?
On 03/11/2013 07:09 PM, Kevin Chadwick wrote: No, there was simply no useful result that came up. Incidentally, both links you provide *did* come up...but I dismissed them because I couldn't imagine anyone using them as a reference except in trying to deride Henning Brauer. http://marc.info/?l=openbsd-miscm=129666298029771w=2 He goes from advocating NAT444 to a spew of pejoratives about something. NAT444 is one of the nastiest, user-disempowering things to hit the Internet to date. The rest of this email is him bitching about having to parse CIDR notation. How disengenuous. He certainly doesn't. Advocacy of NAT444: who sez that your made up isp has to hand out network-wide unique IPs to his customers? Bitching about having to parse CIDR: look at the oh so bright future yourself, look at the code required to deal with that misdesigned piece of shit. did i just say designed? sorry. it's obvious that nothing remotely related to design was involved. Did you miss the sarcasm. Pretty sure I didn't. The only reason he advocates is because others using it allow him to keep running ipv4 pure networks. That's some useful context. After that I'm sure you can forgive me if I note him to have absolutely no reason to be biased and give him a bit more credit and take his experience of writing one of the best and widely used interrupt driven firewalls and so code to deal with ipv6, helping get the netqmail patch sorted and runs his own decent sized network So he's a smart guy with a decent amount of experience. That doesn't make him right. Let me tell you about a similar guy I know. Let's start with my biological father. He started programming as a kid when he got his hands on a 6802 evaluation board, wrote his own operating systems, had a hand in designing the bar code format the US postal service uses for sorting and routing, and provided the local municipality with its first remote electronic monitoring of its water tower. He was one of the first people to jump into Windows NT, with Windows NT 3.51, as he understood the value the NT kernel offered over the DOS-based versions of Windows. He was quite a guy. But he wasn't always right. He *hated* the transition from MFM to IDE drives, as he wasn't able to perform the kinds of diagnostics he wanted to. Once he latched on to Windows NT, he never let go of Microsoft for a second. He didn't see a point to POSIX, UNIX or Linux, and I was never able to get him interested. With the exception of things written or distributed by Microsoft, he never used third-party tools, and had to write everything from the ground-up the way he wanted it. When given specs by other people, he would hand them a product that was what he thought they needed, not what they asked for. He further never felt the need to work with or learn from anyone else in his field. He's brilliant. Quite literally an accomplished genius...but once he got it in his head that he knew what needed to be known, there wasn't room for much new, and there wasn't room for much new. I've tried working with him in architecting web services, and I couldn't. He rejected the idea of using any existing data serialization or transport format, because it wouldn't be as efficient as something he could write. His system architecture relied on a central synchronous component, but the goal of the system was supposed to support scaling. (It couldn't.) Just because he was amazing and awesome among his contemporaries in the past doesn't say anything about his relative skill and knowledge in the present. over yours who I am sure is genuine but could well be partial to ipv6 because as you say you teach setting up ipv6 networks. You need to analyze things on their technical merits, not just on who says them. I won't ask someone to use IPv6 where it's inappropriate. I do believe in pragmatic solutions (systemd and merged /usr notwithstanding ;) ). I don't generally hold for Ludditism. If someone wants to actively reject a technology, I'd like to at least make sure it's for the right reasons. http://marc.info/?l=openbsd-miscm=124536321827774w=2 True enough. And since we're there, it's critical that people learn how to handle their problems. http://marc.info/?l=openbsd-miscm=135325826302392w=2 This email has absolutely no technical content whatsoever. Did you not follow the threads? No. If you want me to read something, you need to point at what I should read. You didn't indicate I should be reading a thread (as opposed to an individual message...) I couldn't find the juicier threads about client troubles due to added complexity but here's some relevent ones and many by very competent devs. (and if I'm honest who tend to shadow every other list I've come across so far as long as you are not timid and can take a hit, though Gentoo is up there). http://marc.info/?l=openbsd-miscm=128822984018595w=2 Re: ARP -- Sure, they don't like ND. That's fine; we
