Re: [gentoo-user] Serious problem with linode vm

[Michael Mol]

On 04/15/2013 11:37 AM, Tanstaafl wrote:
> Hi all,
> 
> Help! :(

[snip]

> 
> I've tried recompiling both (both compile/install ok), but when I try to
> start SSHD I get:
> 
>  # /etc/init.d/sshd start
> /etc/init.d/sshd: line 18: 2079 Illegal instruction "${SSHD_BINARY}" -t
> ${SSHD_OPTS}
> * ERROR: sshd failed to start

^^ That screams 'CFLAGS' issue. Verify that the CFLAGS for your prod
server are the same (or close enough) to that of your dev server.

Guessing the new host has different CPU capabilities exposed to the
guest, either because of a differing hypervisor configuraiton, or
because of the different underlying hardware.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] which machine to buy for perfect gentoo machine?!

[Michael Mol]

On 04/14/2013 04:32 AM, Pandu Poluan wrote:
> 
> On Apr 14, 2013 1:27 PM, "Michael Mol"  <mailto:mike...@gmail.com>> wrote:
>>
>> On 04/14/2013 01:55 AM, Pandu Poluan wrote:
>> >
>> > On Apr 14, 2013 1:42 AM, "Michael Mol"  <mailto:mike...@gmail.com>
>> > <mailto:mike...@gmail.com <mailto:mike...@gmail.com>>> wrote:
>> >>
>>
>> [snip]
>>
>> >
>> > What I meant was: given 4 physical AMD cores (but only 2 FPUs, courtesy
>> > of AMD's Bulldozer/Piledriver arch) vs 4 virtual Intel cores (2 cores
>> > split into 4 by Hyperthreading), I undoubtedly prefer 4 physical ones.
>> >
>> > (Of course if the Intel CPU has 4 pphysical cores, it should be compared
>> > with an 8-core AMD CPU).
>> >
>> > I had some lively discussion on AMD vs Intel *for virtualization* in the
>> > Gentoo Community on Google+, which referenced a thread on ServerFault.
>> > The conclusion was: Intel CPUs (provided they support VT-x) can run
>> > baremetal virtualization as well as AMD, in the majority of cases.
>> >
>> > It's the minority of cases -- edge cases -- that I'm concerned with.
>> > And, lacking the money to actually buy 2 complete systems to perform
>> > comparison, I'll take the safe route anytime.
>> >
>> > Yes, Intel's top-of-the-line processors might be faster than AMD's, but
>> > the latter is cheaper, and exhibited a much more 'stable' performance
>> > (i.e., no edge cases to bite me later down the road).
>> >
>> > That said, I read somewhere about the 'misimplementation' of some
>> > hypercalls in Intel CPUs... in which some hypercall exceptions are
>> > mistakenly handled by the Ring 0 hypervisor instead of the Ring 1 guest
>> > OS, thus enabling someone to 'break out' of the VM's space. This
>> > misimplementation is exploitable on KVM and Xen (the latter, my
>> > preferred baremetal virtualization).
>>
>> That's actually very interesting. I hadn't heard about this.
>>
> 
> Here you go:
> 
> http://blog.xen.org/index.php/2012/06/13/the-intel-sysret-privilege-escalation/
> 
> It's CVE-2012-0217, and the guys from vupen actually has created a
> working proof:
> 
> http://www.vupen.com/blog/20120904.Advanced_Exploitation_of_Xen_Sysret_VM_Escape_CVE-2012-0217.php
>

Interesting! It also sounds like it's reasonably generally fixed with a
patch to the hypervisor.

Too bad hypervisors tend to have extremely long uptimes.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] which machine to buy for perfect gentoo machine?!

[Michael Mol]

On 04/14/2013 01:55 AM, Pandu Poluan wrote:
> 
> On Apr 14, 2013 1:42 AM, "Michael Mol"  <mailto:mike...@gmail.com>> wrote:
>>

[snip]

> 
> What I meant was: given 4 physical AMD cores (but only 2 FPUs, courtesy
> of AMD's Bulldozer/Piledriver arch) vs 4 virtual Intel cores (2 cores
> split into 4 by Hyperthreading), I undoubtedly prefer 4 physical ones.
> 
> (Of course if the Intel CPU has 4 pphysical cores, it should be compared
> with an 8-core AMD CPU).
> 
> I had some lively discussion on AMD vs Intel *for virtualization* in the
> Gentoo Community on Google+, which referenced a thread on ServerFault.
> The conclusion was: Intel CPUs (provided they support VT-x) can run
> baremetal virtualization as well as AMD, in the majority of cases.
> 
> It's the minority of cases -- edge cases -- that I'm concerned with.
> And, lacking the money to actually buy 2 complete systems to perform
> comparison, I'll take the safe route anytime.
> 
> Yes, Intel's top-of-the-line processors might be faster than AMD's, but
> the latter is cheaper, and exhibited a much more 'stable' performance
> (i.e., no edge cases to bite me later down the road).
> 
> That said, I read somewhere about the 'misimplementation' of some
> hypercalls in Intel CPUs... in which some hypercall exceptions are
> mistakenly handled by the Ring 0 hypervisor instead of the Ring 1 guest
> OS, thus enabling someone to 'break out' of the VM's space. This
> misimplementation is exploitable on KVM and Xen (the latter, my
> preferred baremetal virtualization).

That's actually very interesting. I hadn't heard about this.

> 
>> >
>> > I much prefer having 4 actual cores than 4 virtual cores (only 2
>> > actual cores); less chance of things messing up royally if I hit some
>> > edge cases where Hyperthreading falls flat on its face.
>>
>> Whatever works. I'll note that AMD's piledriver core does something very
>> complementary to hyperthreading. Where HT uses some circuitry to avoid
>> context switching when changing whether a core is handling one thread vs
>> another thread, Piledriver has a small number of physical front-end
>> cores dispatching to a larger number of backend pipelines. It's a very
>> curious architecture, and I look forward to seeing how it plays out. HT
>> and Piledriver are conceptually very similar when you look at them in
>> the right way...Piledriver might be seen as a more general approach to
>> what HT does.
>>
> 
> True. The main complexity is when an instruction requires access to the
> FPU, since there's only one FPU per two GP cores. This will somewhat
> impact applications that uses the FPU heavily... except if they can
> switch to OpenCL and leverage the embedded Radeon on AMD's so-called "APUs".
> 

Intel's on-die GPGPU looks promising in that regard, too. As a guy who
likes to do heavy bulk float crunching in HDR imagery, I'm looking
forward to OpenCL improvements.

>> Personally, I've enjoyed both Intel and AMD processors. Last I assembled
>> a system, Intel's midrange offered more bang for the buck than AMD, but
>> Intel's midrange part was also much more expensive. OTOH, AMD systems
>> could be upgraded for piece by piece for much, much, much longer,
>> whereas Intel systems tended to require replacing many more parts at the
>> same time.
>>
>> That was about five years ago, though...I don't know exactly where
>> things sit today. I'd start with the cpubenchmarking.net
> <http://cpubenchmarking.net> CPU value
>> listing, and find the best-value part that has the performance degree
>> I'm looking for.
>>
>> http://cpubenchmark.net/cpu_value_available.html
>>
>> I might also cross-reference that page with this one:
>>
>> http://cpubenchmark.net/mid_range_cpus.html
>>
> 
> True. My desktop computer died on me about 6 months ago. It was 4.5
> years old at the moment of death. It had served me very well.
> 
> That said, my brother had just purchased an AMD system (store-assembled)
> with an FX-8350, and he said that it's faster than anything he's ever
> used before, and he's used many high-end systems in his job (he's a
> Petroleum Geologist, his line of work involves analyzing a HUGE amount
> of data to find out the 'oil potential' of an area, to give his company
> a ballpark figure on how much to bid for the exploitation rights to the
> area).

My "desktop box" has two Xeon E5345s. When I looked it up, I was amazed
that the FX-8320 has *twice* the cpumark

Re: [gentoo-user] which machine to buy for perfect gentoo machine?!

[Michael Mol]

On 04/13/2013 05:49 PM, Frank Steinmetzger wrote:
> On Sat, Apr 13, 2013 at 02:44:20PM -0400, Michael Mol wrote:
> 
>>> I'm currently holding out on my Core2 though, because Haswell is on the
>>> doorstep, and I first wanna see what the market has to offer. The CPU part
>>> might not gain much in performance, but the graphics part got a big boost 
>>> and
>>> all models support VT-d now (according to cpu-world.com). Plus theoretically
>>> I'm a bit more future-proof due to the new socket (which is probably the 
>>> most
>>> annoying thing about the Intel world, compared to AMD).
>>>
>>
>> Be very careful. This laptop's processor does not have VT-x...and that
>> bit me.
> 
> At some point I found out that on my laptop I couldn't use VT-x either, even
> though the processor was supposed to support it. Doing a bit of digging in the
> tubes I found out that on many laptop it was disabled, and naturally the
> there was no option in the BIOS to enable it (even though it is a Pro line
> model, Samsung P50 for those who are interested). Thankfully, I found a
> (Windows) tool that would change that by doing some NVRAM voodoo.
> 
>> […]
>> If buying an Intel part, I'd be very, very careful to make sure that it
>> supported all the features I want. I've been bit by that on this
>> laptop...I had no idea it wouldn't have VT-x.
> 
> Well, in my (our?) case, it's a BIOS issue. I don't expect such issues for
> desktop systems which you built from scratch yourself. I wouldn't see a point
> for the manufacturer to artificially reduce functionality, because here it is
> very easy to buy a directly competing product. But I think I'm getting OT.
> 

You  can also look up the part directly on Intel's website. In my case:

http://ark.intel.com/products/55626/Intel-Pentium-Processor-B940-(2M-Cache-2_00-GHz)

Relevant line:

Intel® Virtualization Technology (VT-x) No





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] which machine to buy for perfect gentoo machine?!

[Michael Mol]

On 04/13/2013 01:50 PM, Frank Steinmetzger wrote:
> On Sat, Apr 13, 2013 at 07:03:26AM +0200, Tamer Higazi wrote:
>> Hi people!
>> My old core2duo machine says slowly goodbye and I am at this lever after
>> 7 years for buying myself a new developer machine, that should serve me
>> well for a long time again. With intel I never had problems, all their
>> systems were REALLY stable, and they were really worth their money up to
>> the last cent.
> 
> Same situation here -- Core2 Duo T7200 (2 GHz max, but throttled due to
> worn-down heatpipe). I'll be buying a new system, too, soon.
> 
> As to the other issues of the thread:
> all intel Cores have VT-x (including Core2, by the way), which is basic
> virtualisation support. What only a select few have is VT-d, which is I/O
> virtualisation. As for the confusion about model range and hyperthreading,
> Wikipedia has a very nice comparison chart of all available models:
> http://en.wikipedia.org/wiki/Ivy_Bridge_(microarchitecture)#Desktop_processors
> 
> Basically:
>   i3 = dual-core with HT (2 physical/4 logical cores), no turbo mode
>   i5 = quad-core without HT (4/4, except one low-TDP model, which is 2/4)
>   i7 = quad-core with HT (4/8)
> 
> I don't know the technical details very well, but because my Netbook has a
> single-core CPU with HT, I read up on it a bit. As I understand it, HT allows
> two threads to use the same core simultaneously, if they don't use the same
> instruction circuitry. Hence a hyper-threaded single-core is not as fast as
> a proper dual-core, because sometimes one thread still has to wait.
> 
>> There are 3 choices:
>>
>> Intel Xeon E5-2650
>> Core i7 3979 extreme edition
>> AMD FX.8350 CPU
> 
> Everything Intel with Extreme in the name is, in my opinion, overpriced for
> its bang. If you really need as much bang as possible and afford it (like when
> you earn your money with that bang), then why not.
> But if you say your Core2 served you well, then you could go a more pragmatic
> approach of "3 times more power than before is enough for me" and save a few
> 100 bucks, or maybe invest in a bigger SSD instead.
> 
> 
> I'm currently holding out on my Core2 though, because Haswell is on the
> doorstep, and I first wanna see what the market has to offer. The CPU part
> might not gain much in performance, but the graphics part got a big boost and
> all models support VT-d now (according to cpu-world.com). Plus theoretically
> I'm a bit more future-proof due to the new socket (which is probably the most
> annoying thing about the Intel world, compared to AMD).
> 

Be very careful. This laptop's processor does not have VT-x...and that
bit me.

$ cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 42
model name  : Intel(R) Pentium(R) CPU B940 @ 2.00GHz
stepping: 7
microcode   : 0x14
cpu MHz : 800.000
cache size  : 2048 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 2
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor
ds_cpl est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt
tsc_deadline_timer xsave lahf_lm arat epb xsaveopt pln pts dtherm
bogomips: 3990.81
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 42
model name  : Intel(R) Pentium(R) CPU B940 @ 2.00GHz
stepping: 7
microcode   : 0x14
cpu MHz : 800.000
cache size  : 2048 KB
physical id : 0
siblings: 2
core id : 1
cpu cores   : 2
apicid  : 2
initial apicid  : 2
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor
ds_cpl est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt
tsc_deadline_timer xsave lahf_lm arat epb xsaveopt pln pts dtherm
bogomips: 3990.81
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:


Anyway (copying from what I just sent in response to Pandu)...

Personally, I've enjoyed both Intel and AMD processors. Last I assembled
a system, Intel's midrange offered more bang for the buck than AMD, but
Intel's midrange part was also much more expensive. OTOH, AMD systems
could be upgraded for piece by p

Re: [gentoo-user] which machine to buy for perfect gentoo machine?!

[Michael Mol]

On 04/13/2013 01:45 PM, Pandu Poluan wrote:
> 
[snip]

> Three, AMD has no concept of Hyperthreading.

Correct.

> Just match -j to the number of cores your CPU provides, and that's
> it.

Well, YMMV. You can spend a lot of time adjusting -j on a per-system
basis to account for things like I/O. Right now, I'm in the "-j
$(cores*1.5) -l $(cores)" camp.

> 
> As I wrote, an AMD Quad Core provides actual 4 cores.

Correct.

> An "Intel Quad Core with Hyperthreading" actually provides only 2
> physical cores, but then it performs some internal trickery so the OS
> sees a total of 4 cores.

Incorrect. Intel Quad Core with Hyperthreading means there are four
physical cores, and there is hyperthreading enabled. This results in the
OS seeing eight logical cores. There is sufficient information available
via ACPI (or is it DMI?) that the kernel knows which virtual cores are
part of which physical cores, which physical cores are part of which CPU
packages, and how everything is connected together.

> 
> I much prefer having 4 actual cores than 4 virtual cores (only 2
> actual cores); less chance of things messing up royally if I hit some
> edge cases where Hyperthreading falls flat on its face.

Whatever works. I'll note that AMD's piledriver core does something very
complementary to hyperthreading. Where HT uses some circuitry to avoid
context switching when changing whether a core is handling one thread vs
another thread, Piledriver has a small number of physical front-end
cores dispatching to a larger number of backend pipelines. It's a very
curious architecture, and I look forward to seeing how it plays out. HT
and Piledriver are conceptually very similar when you look at them in
the right way...Piledriver might be seen as a more general approach to
what HT does.

Personally, I've enjoyed both Intel and AMD processors. Last I assembled
a system, Intel's midrange offered more bang for the buck than AMD, but
Intel's midrange part was also much more expensive. OTOH, AMD systems
could be upgraded for piece by piece for much, much, much longer,
whereas Intel systems tended to require replacing many more parts at the
same time.

That was about five years ago, though...I don't know exactly where
things sit today. I'd start with the cpubenchmarking.net CPU value
listing, and find the best-value part that has the performance degree
I'm looking for.

http://cpubenchmark.net/cpu_value_available.html

I might also cross-reference that page with this one:

http://cpubenchmark.net/mid_range_cpus.html

If buying an Intel part, I'd be very, very careful to make sure that it
supported all the features I want. I've been bit by that on this
laptop...I had no idea it wouldn't have VT-x.



signature.asc
Description: OpenPGP digital signature

[gentoo-user] Re: About to embark on x32

[Michael Mol]

On 04/09/2013 09:46 PM, Michael Mol wrote:
> So I'm about to try setting up the x32 arch in a VM. I notice there's no
> handbook for it, though there is for amd64 and x86. I'm considering x32
> for its lighter memory footprint...
> 
> Does anyone know of any notable differences between the setup process
> for amd64 and x32, or should I expect things to be relatively smooth?
> 

Well, scratch that. Segfault on the chroot step.



signature.asc
Description: OpenPGP digital signature

[gentoo-user] About to embark on x32

[Michael Mol]

So I'm about to try setting up the x32 arch in a VM. I notice there's no
handbook for it, though there is for amd64 and x86. I'm considering x32
for its lighter memory footprint...

Does anyone know of any notable differences between the setup process
for amd64 and x32, or should I expect things to be relatively smooth?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!

[Michael Mol]

On 04/09/2013 06:02 AM, Tanstaafl wrote:
> On 2013-04-08 3:56 PM, Bruce Hill  wrote:
>> Since Gentoo now recommends GrUB rather by default, it might be nice
>> for folks to know how to use this.
> 
> ? So the handbook used to recommend LILO? I installed my first gentoo
> box back in about 2004/2005, and grub was 'the way'...
> 
> Personally, I didn't know people still used LILO (no flame intended, I
> just didn't realize it was still alive and kicking), but then gentoo was
> my first real experience with linux...
> 

It's not. (And neither is GRUB prior to GRUB2.) But it's Stable Enough
that that it still works for a lot of people. Some folks swear by it...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!

[Michael Mol]

On 04/08/2013 12:28 PM, Bruce Hill wrote:
> On Sat, Apr 06, 2013 at 10:58:38PM -0400, Randy Barlow wrote:
>> On Sat, 6 Apr 2013 22:35:22 -0400
>> Nick Khamis  wrote:
>>> As for /sbin/ip. I have no such command.
>>
>> I'd recommend installing and becoming familiar with the iproute2
>> package. I personally find the tools it delivers to be more intuitive
>> than the older tools, and I *think* they are considered to obsolote some
>> tools, such as ifconfig.
> 
> Ack to Randy's. FWIW: http://inai.de/2008/02/19
> 

That page has a handy list at the end. I've gone back to the page twice
today...bookmarked.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!

[Michael Mol]

On 04/08/2013 12:04 PM, Bruce Hill wrote:
> On Sun, Apr 07, 2013 at 09:31:43PM +0100, Neil Bothwick wrote:
>> On Sun, 07 Apr 2013 13:16:45 -0400, Tanstaafl wrote:
>>
>>> "If /etc/udev/rules.d/80-net-name-slot.rules is an empty file or a
>>> symlink to /dev/null,"
>>>
>>> The first can obviously be taken quite literally, while the second just 
>>> might actually require a tiny bit of thought - ie, 'hmmm, wonder if
>>> they mean literally 'empty', or just nothing in it that does anything?
>>
>> Even if that were reasonable, how are you supposed to know which they
>> mean? You guessed right and now have the benefit of hindsight, that does
>> not justify ambiguous or inaccurate instructions.
> 
> Ack!
> 
> Empty means a zero byte file ... always has, and if the idiots who have
> started systemd and taken over udev have somehow managed to change that, then
> we are not going to be able to trust ANYTHING they ever write again, without a
> new dictionary to define their terms. (Sounds like the present POTUS,
> Congress, and Supreme Court in the U.S.)
> 
> Personally I don't now, nor have ever, trusted Kay and Lennart. I depend upon
> WilliamH to keep the ship afloat as we sail through the udev murk...
> 

The phrase is "kernel-tinted glasses".




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Pidgin, gtalk and jingle

[Michael Mol]

On 04/08/2013 11:39 AM, Nilesh Govindrajan wrote:
> On Apr 8, 2013 9:07 PM, "Michael Hampicke"  <mailto:gentoo-u...@hadt.biz>> wrote:
>>
>> Am 08.04.2013 17:20, schrieb Michael Mol:
>> > So, I'm trying to verify whether or not Pidgin can talk to Google Voice
>> > on my laptop. When searching around for instructions, I get the
>> > impression that this is supposed to "just work", and I don't see much in
>> > the way of people actually having difficulty with it.
>> >
>> > In my case, if someone calls me, my gmail tab rings at me, my phone
>> > rings at me, but Pidgin doesn't so much as twitch.
>> >
>> > Has anyone else had this working on Gentoo?
>> >
>> > Here's what I'm working with:
>> >
>> > net-im/pidgin-2.10.7-r1 was built with the following:
>> > USE="dbus doc gnutls gstreamer gtk (multilib) ncurses networkmanager nls
>> > python spell tk xscreensaver zeroconf (-aqua) -debug -eds -gadu
>> > -groupwise -idn -meanwhile -perl -prediction -sasl -silc -tcl -zephyr"
>> > ABI_X86="64"
>> >
>>
>> I never got this to work either. I tried google-voice-calling ( :-) )
>> myself from my android phone to pidgin on the work station and got
>> nothing. Also I cannot make outgoing calls from pidgin to my android
> phone.
>>
> 
> Same here. It seems Google Talk uses some different protocol unlike
> pidgin which uses jingle. Pidgin to pidgin calling works.
> 

On my wife's workstation (running Windows), I'm told it works; pidgin
tells her someone's calling when someone calls her google voice number.
(She ignores it, though, since she doesn't actively use Pidgin for voice.)

So Pidgin is capable of talking to Google's variant on XMPP-Jingle, but
for whatever reason it doesn't seem to work on Gentoo, from the sound of it.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Michael Mol]

On 04/08/2013 11:04 AM, Bruce Hill wrote:
> On Sun, Apr 07, 2013 at 03:09:43PM -0500, William Hubbs wrote:
>> On Sat, Apr 06, 2013 at 10:25:50AM -0400, Tanstaafl wrote:
>>> On 2013-04-05 4:11 PM, William Hubbs  wrote:
 On Fri, Apr 05, 2013 at 02:38:21PM -0500, Bruce Hill wrote:
> Just dealing with one server and my Linux router, they've been updated to
> sys-fs/udev-200 and are both still using the same
> /etc/udev/rules.d/70-persistent-net.rules file they've had for over a 
> year,
> which was working with udev-171.

 Do you have your network interface drivers built into the kernel or are
 they modules?
>>>
>>> I'm very interested in the significance of this question...
>>>
>>> My server is module free, so all drivers are built into the kernel.
>>
>> The significance is that the kernel determines the eth* name order.
>> Right now, you are lucky in that the order is what you think it should
>> be, but if something changes in the kernel causing your cards to be
>> initialized in a different order, you will not be allowed to swap them
>> around in the eth* name space, e.g. eth1 can't become eth0 or visa
>> versa.
>>
>> That is why it is recommended that you use something like net0, net1,
>> etc for your interface names.
> 
> Thanks for your reply. After 10 years of eth* it's going to be hard to make a
> change until the kernel does this, also.

No kidding. There's almost 30 years' documentation out there that
assumes 'eth0' is the interface you care about, except in cases where
you care about 'eth0' and 'eth1'.

As far as the kernel namespace issue...there needs to be a different
namespace between what the kernel defines and what udev can control; at
the moment, if you define your own NIC names (say, wan1, wan2), there's
a chance that a kernel driver will stomp on it if you start using a card
that has a driver that likes that numbering scheme.



signature.asc
Description: OpenPGP digital signature

[gentoo-user] Pidgin, gtalk and jingle

[Michael Mol]

So, I'm trying to verify whether or not Pidgin can talk to Google Voice
on my laptop. When searching around for instructions, I get the
impression that this is supposed to "just work", and I don't see much in
the way of people actually having difficulty with it.

In my case, if someone calls me, my gmail tab rings at me, my phone
rings at me, but Pidgin doesn't so much as twitch.

Has anyone else had this working on Gentoo?

Here's what I'm working with:

net-im/pidgin-2.10.7-r1 was built with the following:
USE="dbus doc gnutls gstreamer gtk (multilib) ncurses networkmanager nls
python spell tk xscreensaver zeroconf (-aqua) -debug -eds -gadu
-groupwise -idn -meanwhile -perl -prediction -sasl -silc -tcl -zephyr"
ABI_X86="64"



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!

[Michael Mol]

Are you using 802.1x or wireless on that machine? If not, I can't think
of a reason you'd need it, outside of it being a hard dependency of some
other package.

On 04/07/2013 10:22 AM, Nick Khamis wrote:
> Installing wpa_supplicant got the network scripts working again. Not
> sure why. Does anyone know why we need wpa_supplication now?
> 
> On 4/7/13, Nick Khamis  wrote:
>> I am upgrading each package (25) one by one, and leaving the meat and
>> potatoes (udev) for last. I am really sorry about the noise guys and
>> gals. It's been a while since I had such a scare
>> There are 4500 people coming into work tomorrow morning, and this
>> machine also happens to be our LDAP server.
>>
>> N.
>>
>> On 4/7/13, Neil Bothwick  wrote:
>>> On Sun, 7 Apr 2013 09:38:23 -0400, Nick Khamis wrote:
>>>
 Double checking the udevd version we are running 171. Not sure if we
 should be effected yet? I confess, I did a world upgrade and walked
 away. For some reason it was stuck on ipr.h for some apache related
 package, which was odd since apache is not installed on the machine.
 I reset the system and poof Here I am at the co-location on Sunday
 at 9:00am.
 Serves me right I guess.

 I double checked. When deleting 70-something rules and restarting the
 machine they get regenerated.
>>>
>>> That's how udev-171 was supposed to work. You need to update to 200 then
>>> delete the file and it will stay deleted.
>>>
>>> You really need to read the news item and associated page CAREFULLY, then
>>> work through them CAREFULLY and the upgrade should do just what you want.
>>>
>>> udev, or whatever device manager you choose, is a critical system
>>> component, not the sort of thing you should leave to update itself
>>> without reading the instructions, especially on a remote server.
>>>
>>>
>>> --
>>> Neil Bothwick
>>>
>>> MICROSOFT: Most Intelligent Customers Realize Our Software Only Fools
>>> Teenagers
>>>
>>
> 




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!

[Michael Mol]

On 04/07/2013 10:01 AM, Nick Khamis wrote:
> Manually bringing up eth0 using ifconfig got me up and running. It's
> quite shaky though. net.eth0 does not work any more and of course
> neither does sshd or any other service that requires net.eth*. Thanks
> Michael.
> 
>>> If they're supposed to be configured via DHCP, try "dhclient
>>> $interface_name". If they're supposed to be statically configured, try
>>> using ifconfig to configure them manually.
> 
> Now that I have internet connection, I am not sure what my line of
> action should be.

Figure out why you're still running udev-171. I suspect your errors come
from having the old version of udev after everything updated around it.

Or switch to mdev or eudev. Your call...but your old udev is probably at
the heart of your problem.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Michael Mol]

On 04/06/2013 11:06 PM, Grant Edwards wrote:
> On 2013-04-06, Pandu Poluan  wrote:
> 
>> Ahhh... I think now I understand...
>>
>> So. Here's my summarization of the situation:
>>
>> * The ethX naming can change, i.e., the interfaces can get out of order
>> * So, to fix this, udev decided to use the physical attachment points of
>> the NIC in driving a persistent name, a name that will be identical across
>> boots as long as there is no hardware change
>> * In doing so, it also frees the 'traditional' ethX names to be used
>> * If one wants, one can still 'rename' the NICs to the 'traditional' names
>> using the 70-*.rules script
> 
> Wha?  I swear I was told that you could not reliably name the
> iterfaces eth[0-n] using udev rules (which is what I've always done
> without problems) because of "race conditions".  So I changed over to
> net[0-n] on one machine, and was planning on doing so on the others
> soon.
> 
> Can we still use udev rules to name interfaces eth[0-n] or not?
> 

If and only if there is no device named ethN when you go to name a
device ethN. That's what's meant by 'reliably'.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!

[Michael Mol]

On 04/06/2013 11:19 PM, Nick Khamis wrote:
> Hello Michael,
> 
>>> Is it because you disabled udev's renaming entirely via the kernel 
>>> command-line parameter? >> Because you've done some magic in 
>>> /etc/udev/rules.d/?
> 
> I did not change 70-something contents. I deleted it and let udev regenerate 
> it.
> 
> The name in rules.d is net=eth0 and net=eth1 pointing to the correct
> mac address.
> 
> Your help is greatly appreciated,

Just an FYI...when I removed them, udev did not regenerate them. You
might try removing them again (or moving them to ~root/ for
safekeeping), rebooting, and seeing what happens.

That udev regenerated them for you is very, very weird.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!

[Michael Mol]

The problem is that the definition of 'correctly' has changed. I don't
know if this is 'correctly' from your perspective of 'this is how I'm
used to seeing it' or 'correctly' from any of the three or more ways one
could use udev. The various defintions of 'correctly' may not overlap.

If they're showing up as eth0/eth1...why? Is it because you disabled
udev's renaming entirely via the kernel command-line parameter? Because
you've done some magic in /etc/udev/rules.d/?

If the former, then OK, this is a different issue. If the latter, be
aware that this isn't a supported configuration! You may very well have
to rename your interfaces before this is done, or let udev rename them
for you.

On 04/06/2013 10:55 PM, Nick Khamis wrote:
> ifconfig -a and ifconfig eth0 etc.. lists the interfaces correctly.
> When trying to start net.eth0 the error that struck me as odd was:
> 
> /lib64/rc/net/wpa_supplicant.sh: line 68: _is_wireless: command not found
> /etc/init.d/net.eth0: line 548: _exists: command not found
> 
> Sorry I can't paste stuff directly. I am literally taking phone pics
> and communicating through my laptop.
> 
> N.
> 
> On 4/6/13, Michael Mol  wrote:
>> It's probably not a module issue.
>>
>> Are these interfaces supposed to be DHCP-configured, or are they
>> supposed to be statically and locally configured?
>>
>> If they're supposed to be configured via DHCP, try "dhclient
>> $interface_name". If they're supposed to be statically configured, try
>> using ifconfig to configure them manually.
>>
>> Also, ipmaddr is *not* the command you should be using. That deals
>> strictly in multicast addresses, not unicast addresses. I presume you're
>> trying to get your unicast addresses working properly.
>>
>> ifconfig -a
>>
>> On 04/06/2013 10:35 PM, Nick Khamis wrote:
>>> Sorry I did mean /sbin/ip... Long day. Regardless, /sbin/ipmaddr does
>>> now show any ipv4 related material. Other than the network card
>>> driver, what module should I ensure is loaded for ipv4 related stuff.
>>> As for /etc/conf.d/net, net.eth0/eth1 these were untouched and still
>>> point to eth0 and eth1.
>>>
>>> As for /sbin/ip. I have no such command.
>>>
>>> N.
>>>
>>>
>>> On 4/6/13, Michael Mol  wrote:
>>>> /sbin/ip, not /etc/ip
>>>>
>>>> Those inet6 addresses beginning with ff02 are link-local addresses.
>>>> Those are automatically configured on a link simply by the link being
>>>> up.
>>>>
>>>> Something is failing to configure your interfaces' ipv4 settings.
>>>>
>>>> The culprit is almost certainly somewhere in one of these places, its
>>>> lack of being in these places it part of your problem:
>>>>
>>>> /etc/conf.d/net
>>>> /etc/init.d/net.*
>>>> /etc/runlevels/*/net.*
>>>>
>>>> Otherwise, try those find/grep lines I offered.
>>>>
>>>> On 04/06/2013 10:01 PM, Nick Khamis wrote:
>>>>> I do not have /etc/ip however, I do have /etc/ipmaddr show:
>>>>>
>>>>> 1: lo
>>>>>inet6 ff02::1
>>>>> 2: sit0
>>>>>inte6 ff02::1
>>>>> 3: eth0
>>>>>link 33:33:00:00:00:01
>>>>>inet6 ff02:1
>>>>> 4: eth1
>>>>> link 33:33:00:00:00:01
>>>>> inet6 ff02:1
>>>>>
>>>>> Too much inte6 for my liking... Did I somehow get rid of ipv4?
>>>>>
>>>>> N.
>>>>>
>>>>> On 4/6/13, Michael Mol  wrote:
>>>>>> On 04/06/2013 08:53 PM, Nick Khamis wrote:
>>>>>>> I took a closer look at /etc/udev/70-something-rules-net and
>>>>>>> /sys/class/net/eth0/ and all the ATTR (i.e., address, type, dev_id)
>>>>>>> line up fine. I did not find a "name" file in /sys/class/net/eth0
>>>>>>> however,
>>>>>>> name=eth0 in etc/udev/70-something-rules-net.
>>>>>>>
>>>>>>> Ifconfig alone returns nothing. Ifconfig eth0/1 and lo returns the
>>>>>>> interface
>>>>>>> with no tx and rx traffic. And no ip address as set in conf.d/net.
>>>>>>>
>>>>>>> Please help guys. Server room is numbing..
>>>>>>
>>>>>> /sbin/ip link addr show
>>>>

Re: [gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!

[Michael Mol]

It's probably not a module issue.

Are these interfaces supposed to be DHCP-configured, or are they
supposed to be statically and locally configured?

If they're supposed to be configured via DHCP, try "dhclient
$interface_name". If they're supposed to be statically configured, try
using ifconfig to configure them manually.

Also, ipmaddr is *not* the command you should be using. That deals
strictly in multicast addresses, not unicast addresses. I presume you're
trying to get your unicast addresses working properly.

ifconfig -a

On 04/06/2013 10:35 PM, Nick Khamis wrote:
> Sorry I did mean /sbin/ip... Long day. Regardless, /sbin/ipmaddr does
> now show any ipv4 related material. Other than the network card
> driver, what module should I ensure is loaded for ipv4 related stuff.
> As for /etc/conf.d/net, net.eth0/eth1 these were untouched and still
> point to eth0 and eth1.
> 
> As for /sbin/ip. I have no such command.
> 
> N.
> 
> 
> On 4/6/13, Michael Mol  wrote:
>> /sbin/ip, not /etc/ip
>>
>> Those inet6 addresses beginning with ff02 are link-local addresses.
>> Those are automatically configured on a link simply by the link being up.
>>
>> Something is failing to configure your interfaces' ipv4 settings.
>>
>> The culprit is almost certainly somewhere in one of these places, its
>> lack of being in these places it part of your problem:
>>
>> /etc/conf.d/net
>> /etc/init.d/net.*
>> /etc/runlevels/*/net.*
>>
>> Otherwise, try those find/grep lines I offered.
>>
>> On 04/06/2013 10:01 PM, Nick Khamis wrote:
>>> I do not have /etc/ip however, I do have /etc/ipmaddr show:
>>>
>>> 1: lo
>>>inet6 ff02::1
>>> 2: sit0
>>>inte6 ff02::1
>>> 3: eth0
>>>link 33:33:00:00:00:01
>>>inet6 ff02:1
>>> 4: eth1
>>> link 33:33:00:00:00:01
>>> inet6 ff02:1
>>>
>>> Too much inte6 for my liking... Did I somehow get rid of ipv4?
>>>
>>> N.
>>>
>>> On 4/6/13, Michael Mol  wrote:
>>>> On 04/06/2013 08:53 PM, Nick Khamis wrote:
>>>>> I took a closer look at /etc/udev/70-something-rules-net and
>>>>> /sys/class/net/eth0/ and all the ATTR (i.e., address, type, dev_id)
>>>>> line up fine. I did not find a "name" file in /sys/class/net/eth0
>>>>> however,
>>>>> name=eth0 in etc/udev/70-something-rules-net.
>>>>>
>>>>> Ifconfig alone returns nothing. Ifconfig eth0/1 and lo returns the
>>>>> interface
>>>>> with no tx and rx traffic. And no ip address as set in conf.d/net.
>>>>>
>>>>> Please help guys. Server room is numbing..
>>>>
>>>> /sbin/ip link addr show
>>>>
>>>> That will tell you the names of your interfaces, as they currently
>>>> exist.
>>>>
>>>> You cannot reliably use 70-persistent-net-rules to assign interfaces
>>>> names which the kernel may chose. This means things like 'eth0' and
>>>> 'wlan0' are unreliable in principle.
>>>>
>>>> Once you know what the interface name will be, rename
>>>> /etc/init.d/net.eth0 to /etc/init.d/net.$YOUR_INTERFACE_NAME_HERE ,
>>>> remove /etc/runlevels/net.eth0 and create a symlink in /etc/runlevels
>>>> pointing at your new /etc/init.d/net.$WHATEVER file.
>>>>
>>>> Then /etc/init.d/net.$WHATEVER restart ... and things should come up, at
>>>> least partially. To find anything else that might be broken:
>>>>
>>>> find /etc|grep eth0
>>>> find /etc -print0|xargs -0 grep eth0|egrep -v ':#'
>>>>
>>>> and rename 'eth0' there to your new interface name.
>>>>
>>>> I just went through this entire process on one of my machines...but I
>>>> wiped all the files out of /etc/udev/rules.d/ and went with udev's new
>>>> defaults, rather than set up my on persistent net rules for this
>>>> machine. (That's a task for another day.)
>>>>
>>>> Frankly, the process is a PITA...and I'm going to go back to a
>>>> persistent-net.rules file in the future; having to go through that
>>>> entire process because of a NIC swap or an upstream behavior tweak is
>>>> not something I care to have to do.
>>>>
>>>>
>>>
>>
>>
>>
> 




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!

[Michael Mol]

/sbin/ip, not /etc/ip

Those inet6 addresses beginning with ff02 are link-local addresses.
Those are automatically configured on a link simply by the link being up.

Something is failing to configure your interfaces' ipv4 settings.

The culprit is almost certainly somewhere in one of these places, its
lack of being in these places it part of your problem:

/etc/conf.d/net
/etc/init.d/net.*
/etc/runlevels/*/net.*

Otherwise, try those find/grep lines I offered.

On 04/06/2013 10:01 PM, Nick Khamis wrote:
> I do not have /etc/ip however, I do have /etc/ipmaddr show:
> 
> 1: lo
>inet6 ff02::1
> 2: sit0
>inte6 ff02::1
> 3: eth0
>link 33:33:00:00:00:01
>inet6 ff02:1
> 4: eth1
> link 33:33:00:00:00:01
> inet6 ff02:1
> 
> Too much inte6 for my liking... Did I somehow get rid of ipv4?
> 
> N.
> 
> On 4/6/13, Michael Mol  wrote:
>> On 04/06/2013 08:53 PM, Nick Khamis wrote:
>>> I took a closer look at /etc/udev/70-something-rules-net and
>>> /sys/class/net/eth0/ and all the ATTR (i.e., address, type, dev_id)
>>> line up fine. I did not find a "name" file in /sys/class/net/eth0
>>> however,
>>> name=eth0 in etc/udev/70-something-rules-net.
>>>
>>> Ifconfig alone returns nothing. Ifconfig eth0/1 and lo returns the
>>> interface
>>> with no tx and rx traffic. And no ip address as set in conf.d/net.
>>>
>>> Please help guys. Server room is numbing..
>>
>> /sbin/ip link addr show
>>
>> That will tell you the names of your interfaces, as they currently exist.
>>
>> You cannot reliably use 70-persistent-net-rules to assign interfaces
>> names which the kernel may chose. This means things like 'eth0' and
>> 'wlan0' are unreliable in principle.
>>
>> Once you know what the interface name will be, rename
>> /etc/init.d/net.eth0 to /etc/init.d/net.$YOUR_INTERFACE_NAME_HERE ,
>> remove /etc/runlevels/net.eth0 and create a symlink in /etc/runlevels
>> pointing at your new /etc/init.d/net.$WHATEVER file.
>>
>> Then /etc/init.d/net.$WHATEVER restart ... and things should come up, at
>> least partially. To find anything else that might be broken:
>>
>> find /etc|grep eth0
>> find /etc -print0|xargs -0 grep eth0|egrep -v ':#'
>>
>> and rename 'eth0' there to your new interface name.
>>
>> I just went through this entire process on one of my machines...but I
>> wiped all the files out of /etc/udev/rules.d/ and went with udev's new
>> defaults, rather than set up my on persistent net rules for this
>> machine. (That's a task for another day.)
>>
>> Frankly, the process is a PITA...and I'm going to go back to a
>> persistent-net.rules file in the future; having to go through that
>> entire process because of a NIC swap or an upstream behavior tweak is
>> not something I care to have to do.
>>
>>
> 




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!

[Michael Mol]

On 04/06/2013 08:53 PM, Nick Khamis wrote:
> I took a closer look at /etc/udev/70-something-rules-net and
> /sys/class/net/eth0/ and all the ATTR (i.e., address, type, dev_id)
> line up fine. I did not find a "name" file in /sys/class/net/eth0 however,
> name=eth0 in etc/udev/70-something-rules-net.
> 
> Ifconfig alone returns nothing. Ifconfig eth0/1 and lo returns the interface
> with no tx and rx traffic. And no ip address as set in conf.d/net.
> 
> Please help guys. Server room is numbing..

/sbin/ip link addr show

That will tell you the names of your interfaces, as they currently exist.

You cannot reliably use 70-persistent-net-rules to assign interfaces
names which the kernel may chose. This means things like 'eth0' and
'wlan0' are unreliable in principle.

Once you know what the interface name will be, rename
/etc/init.d/net.eth0 to /etc/init.d/net.$YOUR_INTERFACE_NAME_HERE ,
remove /etc/runlevels/net.eth0 and create a symlink in /etc/runlevels
pointing at your new /etc/init.d/net.$WHATEVER file.

Then /etc/init.d/net.$WHATEVER restart ... and things should come up, at
least partially. To find anything else that might be broken:

find /etc|grep eth0
find /etc -print0|xargs -0 grep eth0|egrep -v ':#'

and rename 'eth0' there to your new interface name.

I just went through this entire process on one of my machines...but I
wiped all the files out of /etc/udev/rules.d/ and went with udev's new
defaults, rather than set up my on persistent net rules for this
machine. (That's a task for another day.)

Frankly, the process is a PITA...and I'm going to go back to a
persistent-net.rules file in the future; having to go through that
entire process because of a NIC swap or an upstream behavior tweak is
not something I care to have to do.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Michael Mol]

On 04/04/2013 10:59 AM, Grant Edwards wrote:
> On 2013-04-03, Mick  wrote:
>> On Wednesday 03 Apr 2013 20:46:37 Bruce Hill wrote:
>>
>>> Therefore, all's well that's still working! And AFAIR, on at least 2 of
>>> those machines, the 70-persistent-net.rules was never something I did
>>> manually.
>>
>> Right, it used to be auto-generated by udev scripts.  With udev-200 you are 
>> meant to remove it along with any other files from your /etc/udev/rules.d/
> 
> Huh?  I'm supposed to remove all the other rules files as well?
> 
> If we're not supposed to have user-defined rules, how do I do things
> like get various USB/firewire devices named/symlinked properly so that
> my backup drive gets mounted in the right spot, my oscilloscope SW can
> find the right USB "serial" port, and so on...
> 

You're supposed to remove all the files in there that you did not
yourself create.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Michael Mol]

On 04/01/2013 03:26 PM, William Hubbs wrote:
> On Sun, Mar 31, 2013 at 01:44:18PM -0500, Dale wrote:
>> Nuno J. Silva (aka njsg) wrote:
>>> On 2013-03-31, Dale  wrote:
 Nuno J. Silva (aka njsg) wrote:
> On 2013-03-31, Dale  wrote:
>> Pandu Poluan wrote:
>>>
>>> Since it's obvious that upsteam has this "my way or the highway"
>>> mentality, I'm curious about whether eudev (and mdev) exhibits the
>>> same behavior...
>>>
>> I synced yesterday and I didn't see the news alert.   Last eudev update
>> was in Feb. so I *guess* not.  It seems to be a "udev" thing.  That is
>> why I mentioned eudev to someone else that was having this issue with a
>> server setup. 
> I'd guess eudev will eventually do the same, although I hope that, it
> being a separate codebase, makes it easier to adopt some solution like
> the old rule generator, instead of using udev's approach.
>
> The udev upstream may have its issues, but there's actually a point in
> removing this, the approach there was so far was just a dirty hack.
>

 Thing is, it works for me.  The old udev worked, eudev works but I'm not
 sure what hoops I would have to go through to get the new udev working,
 most likely the same ones others here are going through now.  For once,
 I'm not having to deal with some broken issue.  < knock on wood > 

 My current uptime is about 190 days.  May hit it still but I'm certainly
 hoping I don't. 
>>> And, at least now, I have got enough knowledge to know whether it
>>> affects me or not. But the sad thing is that I got most of that
>>> knowledge *after* the first of these versions without the old script was
>>> stabilized.
>>>
>>
>>
>> I switched to eudev when the separate /usr thing popped up.  While I am
>> watching this thread and sort of taking mental notes, I'm hoping this is
>> not a eudev thing, even in the future. 
> 
> You know that both udev and eudev have exactly the same issue with
> separate /usr right?
> 
> The problem there isn't in the udev code, but it has to do with what is
> happening in rules that other packages install.

As I recall, the problem is where the ebuild choses to install the code.
Putting the udev code under /usr forces the issue on systems where it
would otherwise not be an issue.

Putting the udev code under / avoids that issue, but opens up the system
to the "silently fail" thing upstream liked to use as the basis of
"separate /usr is broken"

So, there are three conceivable configurations (initramfs notwithstanding):

1. With systems which don't require /usr binaries before /usr would be
mounted, separate /usr is not a problem.

2. With systems which require /usr binaries for some features before
/usr would be mounted, those features will silently fail.

3. With systems which require /usr binaries to mount /usr, all hell
breaks loose.

Putting the udev code under /usr moves all udev systems from group 2
into group 3. In a sense, this fixes those systems because the admin is
forced to address the silent failures he was previously unaware of. It
also means pissing off a bunch of people who had features silently
failing...but they probably didn't know or care about those features in
the first place.

It also moves all systems from group 1 into group 3...which is simply wrong.

So long as eudev keeps its install path at / instead of /usr, admins in
group 1 will probably be perfectly happy.



signature.asc
Description: OpenPGP digital signature

Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes

[Michael Mol]

On 04/01/2013 09:54 AM, Neil Bothwick wrote:
> On Mon, 01 Apr 2013 09:29:08 -0400, Michael Mol wrote:
> 
>>> MAC addresses are not human-friendly. It would be OK if you could set
>>> up aliases, so your firewall rules could use enaabbccddeeff while you
>>> could still type eth0.
> 
>> Frankly, I never found 'eth0' to be particularly friendly, either. Hence
>> why I like naming my interfaces things like 'wan', 'wifilan' and
>> 'wiredlan'.
> 
> Relative to 'lan' or 'wan', no, but relative to an embedded MAC address?

Honestly, with IPv6, I get so accustomed to recognizing the last three
or four octets of MAC addresses, that idea is starting to grow on me,
too! It's like recognizing phone numbers, really. You eventually just
start remembering enough of the thing to be useful.

If the system isn't smart enough to apply a solid semantic name (like my
'wan', 'wifilan' or 'wiredlan'), I'd rather it not try to apply a
semantic name (eth0 or net0) at all. But you're hearing this come from a
C++ programmer turned network admin, so take that with a grain of salt. :)



signature.asc
Description: OpenPGP digital signature

Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes

[Michael Mol]

On 04/01/2013 09:12 AM, Neil Bothwick wrote:
> On Mon, 1 Apr 2013 13:57:42 +0700, Pandu Poluan wrote:
> 
>> I still don't understand what's so bad with MAC-based identification? I
>> mean, uniqueness defined through MAC Address identity, the system name
>> is just a label...
> 
> MAC addresses are not human-friendly. It would be OK if you could set up
> aliases, so your firewall rules could use enaabbccddeeff while you could
> still type eth0.
> 
> 

Frankly, I never found 'eth0' to be particularly friendly, either. Hence
why I like naming my interfaces things like 'wan', 'wifilan' and 'wiredlan'.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] [way OT but interesting] Massive recent DDOS attack

[Michael Mol]

On 03/31/2013 10:00 PM, Philip Webb wrote:
> 130331 walt wrote:
>> Any of you admin types out there have any grumpy thoughts about this ?
>> http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet
> 
> There was a good story in 'Guardian' :
> 
>   
> http://www.guardian.co.uk/commentisfree/2013/mar/29/cyberwar-spun-shoddy-journalism
> 

The Gizmodo article that Guardian article lauds irritated the hell out
of me. Certainly it was unlikely for the global Internet to collapse.
However, from the details I've read, there was a risk of one or two IXs
failing, and that would have *serious* regional effects.

Whether a chunk of Europe dropping offline qualifies as "breaking the
Internet" is an interesting question. The answer probably depends on
whether or not you're on that continent...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] [way OT but interesting] Massive recent DDOS attack

[Michael Mol]

On 03/31/2013 07:12 PM, walt wrote:
> Any of you admin types out there have any grumpy thoughts about this
> article? :)  Is it really just marketing BS from cloudflare, or is it
> solid stuff?
> 
> http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet
> 
> 

Can't tell one way or another. Certainly the bulk of the events
described are true. Certainly, it's in CF's interest to describe how
they're thwarting a massive DDOS.

And, certainly, they'd lose virtually all credibility if they were
blowing smoke. Lose credibility, and they'd lose a ton of business.

Frankly, I'm *inclined* to believe their description of events on that
basis alone. But that's not absolute.

It's also worth noting who they're protecting, and who the aggressor is.
The organization they're protecting is a high-profile target. The
organization they're protecting against is one whose businesses are
heavily impacted by the latter, *and* who don't share a positive
reputation among most.

That said, when someone in here linked to a spamhaus page a few days
ago, my local CloudFlare cache didn't have a copy of it, so I suspect
spamhaus hasn't been weathering the storm particularly well.

I'm also using CloudFlare for my site (they have a free tier which is
frankly wonderful), and I've observed that whatever means I put in place
to protect myself through them, it's not possible to get 100% coverage;
for CF to work for you, you need to have a public IP address their
servers can query. So long as you have a public IP address, you can be
targeted; it's just a matter of discovering what that IP is. That IP
could be discovered any of a variety of ways, particularly if someone is
able to induce your server to send data outbound. (i.e. an email where
the origin exists in the message headers.)

For at least a couple weeks now, I've been a direct target of some kind
of attack by someone who holds some kind of weird grudge. Originally, it
was a simple SYN flood, but it's lately taken to be a flood of RST
packets claiming to be from a particular CloudFlare IP; the attacker is
trying to disrupt service by terminating proxied connections.

Anyway, if you don't need SSL, I highly recommend CloudFlare's free
tier. If you do need SSL, they have tiers which support that...but I
don't have a budget to spend on it. (OTOH, it's nice enough that my
average page load times have plummeted...and I now have a free global
proxy cache network, despite my only having one backend server...)




signature.asc
Description: OpenPGP digital signature

Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes

[Michael Mol]

On 03/31/2013 03:55 PM, Neil Bothwick wrote:
> On Sun, 31 Mar 2013 15:40:09 +0100, Kevin Chadwick wrote:
> 
>>> instead of pushing a completely
>>> different (and possibly less reliable) naming scheme by default.  
>>
>> Whilst I wouldn't want them changing on me (though if your physically
>> changing the pci slot then you should be able to handle the number
>> change).
> 
> What about USB network adaptors? A user may not even realise they plugged
> it into a different USB slot from last time, yet the device name changes.

Social media is infectious. I was looking for a '+1' button for this...




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] How to prevent a dns amplification attack

[Michael Mol]

On 03/29/2013 07:01 PM, William Kenworthy wrote:
> On 30/03/13 06:34, Paul Hartman wrote:
>> On Thu, Mar 28, 2013 at 7:49 PM, Peter Humphrey
>>  wrote:
>>> On Thursday 28 March 2013 20:53:49 Paul Hartman wrote:
>>>
 In my case, my ISP's DNS servers are slow (several seconds to reply),
 fail randomly when they should resolve, return an IP (which goes to
 their ad-laden "helper" website if you are using a web browser) when
 they should instead return nxdomain, and they have openly admitted to
 selling customer DNS lookup history to marketers for targeted
 advertising.
>>>
>>>
>>>
>>> That is just evil. Have you no alternative to this ISP?
>>
>> Not really.
>>
>> I have a 100 megabit connection through the cable company; my only
>> wired alternative is DSL (1.5 mbit for almost half the price I'm
>> paying for 100mbit). Cellular or satellite are not viable options for
>> me because of comparatively poor value, latency and miniscule data
>> usage caps.
>>
> 
> Can you do a tunnel to a cheap vsp instance that can access an external
> dns, and feed all your dns queries through it?  Considering the problems
> with your existing setup, that looks attractive and you can have sane
> fallbacks if neccessary.
> 
> I tried this to avoid the "Australia Tax" when online shopping overseas
> and the small additional latency didnt seem to be a problem.

Doesn't even need to be that complicated.

Set up a free tunnel with tunnelbroker.net, and use Hurricane Electric's
provided IPv6 DNS servers. They run the tunnel service as a loss-leader,
and if they're doing anything funky with their DNS data, I haven't heard
about it.

Chances are, the local ISP won't be filtering traffic flowing across a
proto41 tunnel. (IPv6 packet as an IPv4 packet payload. It's called a
proto41 tunnel because 41 is placed in the "next protocol" field in the
IPv4 packet.)




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Is 'MAKEOPTS="--jobs --load-average=5"' silly?

[Michael Mol]

On 03/29/2013 01:46 PM, Dale wrote:
> »Q« wrote:
>> On Fri, 29 Mar 2013 16:54:37 +
>> Stroller  wrote:
>>
>>> On 29 March 2013, at 03:36, Nilesh Govindrajan wrote:
> ...
>> I can only imagine he was pointing out that you have a single CPU
>> with four cores in it.
> You're right, of course. I should have said /cores/.
 Cores or CPUs.. in this context it's *almost*, __NOT EXACTLY__ same.
>>> Which is exactly what was so twitch inducing! 
>> Whatever you do, don't read the first sentence at
>> .
>>
>>
>>
> 
> Especially this FIRST part:
> 
> "A *multi-core processor* is a single computing
>  component . . ."
> 
> So, it is a SINGLE component.  To me, CPUs means having more than one
> CPU component, such as dual CPUs or even quad CPUs which used to be
> fairly common. 
> 
> I have a single CPU computer.  It has 4 cores but a single CPU.  I hope
> to upgrade one day to a 8 core CPU.  I'll still have a single CPU
> component installed tho. 
> 
> This is getting really funny.  ROFL  You can tell when the list is
> getting slow when we start parsing each word and each words meaning.  ;-) 

The list hasn't been slow all week. ^^



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] How to prevent a dns amplification attack

[Michael Mol]

On 03/29/2013 09:27 AM, Alan McKinnon wrote:
> On 29/03/2013 10:53, Norman Rieß wrote:
>>> That is just evil. Have you no alternative to this ISP?

  

 -- 

 Peter

  

>> Like free and open DNS servers? ;-) Like the one i am talking about and
>> was told it was unnessesary crap?
> 
> 
> When you describe the service you DO get from your ISP, then we can see
> that rolling your own is the proper alternative for you. Unless your ISP
> block outbound port 53...

It'd be trivial enough for someone in a saner spot to privately offer
him an allowed-clients entry in a DNS server listening on a non-standard
port.

Either way, it's still important he not allow just anybody to connect to
his resolver.

> 
> If you were in Africa, I could give you an alternative but sadly I don't
> think you are in Africa
> 




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] How to prevent a dns amplification attack

[Michael Mol]

On 03/28/2013 04:57 PM, Kevin Chadwick wrote:
> 
>> listened to the dangers and even now simply redesigned DNSSEC.
> 
> Or they could fudge it by making every request requiring padding larger
> than the response. Bandwidth would increase astronomically but amp
> attacks would have to find other avenues.
> 

Infeasible; the requester cannot know the size of the response in
advance. If a packet comes in, and the response is larger than the
request, is it really an amp packet, did the client not know, or is the
server misconfigured and not limiting the response data as much as it could?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] How to prevent a dns amplification attack

[Michael Mol]

On 03/28/2013 04:53 PM, Paul Hartman wrote:
> On Thu, Mar 28, 2013 at 3:02 PM, Alan McKinnon  
> wrote:
 Or just use the ISP's DNS caches. In the vast majority of cases, the ISP
 knows how to do it right and the user does not.
>>>
>>> Generally true, though I've known people to choose not to use ISP caches
>>> owing to the ISP's implementation of things like '*' records, ISPs
>>> applying safety filters against some hostnames, and concerns about the
>>> persistence of ISP request logs.
>>
>> I get a few of those too every now and again. I know for sure in my case
>> their fears are unfounded, but can't prove it. Those few (and they are
>> few) can go ahead and deploy their own cache. I can't stop them, they
>> are free to do it, they are also free to ignore my advice of they choose.
> 
> In my case, my ISP's DNS servers are slow (several seconds to reply),
> fail randomly when they should resolve, return an IP (which goes to
> their ad-laden "helper" website if you are using a web browser) when
> they should instead return nxdomain, and they have openly admitted to
> selling customer DNS lookup history to marketers for targeted
> advertising.

Wow. That's...all the fail.

> 
> Thanks for being one of the good guys. :)
> 

Indeed.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] How to prevent a dns amplification attack

[Michael Mol]

On 03/28/2013 03:16 PM, Alan McKinnon wrote:
> On 28/03/2013 17:38, Michael Mol wrote:
>> On 03/28/2013 04:51 AM, Norman Rieß wrote:
>>> Hello,
>>>
>>> i am using pdns recursor to provide a dns server which should be usable
>>> for everybody.The problem is, that the server seems to be used in dns
>>> amplification attacks.
>>> I googled around on how to prevent this but did not really find
>>> something usefull.
>>>
>>> Does anyone got an idea about this?
>>
>> I'm not sure it can be done. You can't make a resolver available to
>> "everybody" without somebody in that "everybody" group abusing it, and
>> that's exacly what happens in a DNS amplification attack.
>>
>> Restrict your resolver to be accessible only to your network or, at
>> most, those of the specific group of people you're seeking to help.
>>
>> You *might* try restricting the resolver to only respond to TCP requests
>> rather than UDP requests, 
> 
> NO NO NO NO NO
> 
> Under no circumstances ever do this. The service breaks horribly when
> you do this and it has to work even remotely hard. Most likely your ISP
> will outright ban you for that if you use the ISP's caches. I knwo I do,
> and so does every other major ISP in this country.

Er, what? When we're talking about a recursive resolver requiring
clients connecting to it to use TCP, what does upstream care? He's
talking about running his own open DNS server.

> 
> but if the resolver sends response data along
>> with that first SYN+ACK, then nothing is solved, and you've opened
>> yourself up to a SYN flood-based DoS attack. (OTOH, if your resolver
>> went offline as a result of a SYN flood, at least it wouldn't be part of
>> an amplification attack any longer...)
> 
> 
> Or just use the ISP's DNS caches. In the vast majority of cases, the ISP
> knows how to do it right and the user does not.

Generally true, though I've known people to choose not to use ISP caches
owing to the ISP's implementation of things like '*' records, ISPs
applying safety filters against some hostnames, and concerns about the
persistence of ISP request logs.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] How to prevent a dns amplification attack

[Michael Mol]

On 03/28/2013 12:06 PM, Pandu Poluan wrote:
> 
> On Mar 28, 2013 10:38 PM, "Michael Mol"  <mailto:mike...@gmail.com>> wrote:
>>
>> On 03/28/2013 04:51 AM, Norman Rieß wrote:
>> > Hello,
>> >
>> > i am using pdns recursor to provide a dns server which should be usable
>> > for everybody.The problem is, that the server seems to be used in dns
>> > amplification attacks.
>> > I googled around on how to prevent this but did not really find
>> > something usefull.
>> >
>> > Does anyone got an idea about this?
>>
>> I'm not sure it can be done. You can't make a resolver available to
>> "everybody" without somebody in that "everybody" group abusing it, and
>> that's exacly what happens in a DNS amplification attack.
>>
>> Restrict your resolver to be accessible only to your network or, at
>> most, those of the specific group of people you're seeking to help.
>>
>> You *might* try restricting the resolver to only respond to TCP requests
>> rather than UDP requests, but if the resolver sends response data along
>> with that first SYN+ACK, then nothing is solved, and you've opened
>> yourself up to a SYN flood-based DoS attack. (OTOH, if your resolver
>> went offline as a result of a SYN flood, at least it wouldn't be part of
>> an amplification attack any longer...)
>>
> 
> Can't we rate limit UDP DNS request?
> 
> E.g., limit each source IP to, let's say, 1 UDP per second?
> 
> That should be doable easily using iptables.

That makes the resolver highly unreliable for normal use. Many sites
trigger resource grabs from 10-15 different domains. If all but the
first request is dropped due to rate limiting, you're going to have a
very, very broken experience.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] How to prevent a dns amplification attack

[Michael Mol]

On 03/28/2013 04:51 AM, Norman Rieß wrote:
> Hello,
> 
> i am using pdns recursor to provide a dns server which should be usable
> for everybody.The problem is, that the server seems to be used in dns
> amplification attacks.
> I googled around on how to prevent this but did not really find
> something usefull.
> 
> Does anyone got an idea about this?

I'm not sure it can be done. You can't make a resolver available to
"everybody" without somebody in that "everybody" group abusing it, and
that's exacly what happens in a DNS amplification attack.

Restrict your resolver to be accessible only to your network or, at
most, those of the specific group of people you're seeking to help.

You *might* try restricting the resolver to only respond to TCP requests
rather than UDP requests, but if the resolver sends response data along
with that first SYN+ACK, then nothing is solved, and you've opened
yourself up to a SYN flood-based DoS attack. (OTOH, if your resolver
went offline as a result of a SYN flood, at least it wouldn't be part of
an amplification attack any longer...)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: udev blocks systemd etc

[Michael Mol]

On 03/28/2013 10:35 AM, Alan McKinnon wrote:
> On 28/03/2013 15:16, Michael Mol wrote:
>> On 03/28/2013 03:51 AM, J. Roeleveld wrote:
>>> On Thu, March 28, 2013 07:59, Alan McKinnon wrote:
>>>> On 28/03/2013 04:56, Michael Mol wrote:
>>>>> On 03/27/2013 05:51 PM, Alan McKinnon wrote:
>>>>>> On 27/03/2013 22:41, Michael Mol wrote:
>>>>>>> The case for systemd is twofold:
>>>>>>
>>>>>> ...
>>>>>>
>>>>>>> 2) Reduce the amount of CPU and RAM consumed when you're talking about
>>>>>>> booting tens of thousands of instances simultaneously across your
>>>>>>> entire
>>>>>>> infrastructure, or when your server instance might be spun up and down
>>>>>>> six times over the course of a single day.
>>>>>>
>>>>>> I seems to me that this is rather a niche quite-specialized case
>>>>>> (albeit
>>>>>> a rather large instance of a niche case). In which case it would be
>>>>>> better implemented as Redhat MagicSauce for their cloud environment
>>>>>> where it would be exactly tuned to that case's need.
>>>>>
>>>>> But it's a great deal cheaper to convince volunteers and package
>>>>> maintainers to put in the time to build the necessary service files of
>>>>> their own accord. Add in the complexity of parallel boot, and you can
>>>>> induce upstream to fix their own race-driven bugs rather than have to
>>>>> pay for that development directly.
>>>>>
>>>>
>>>> I don't follow the thought stream here Michael.
>>>> It feels like there's a word or a sentence missing (it's just not
>>>> hanging together)
>>>
>>> Alan, I think what Michael is trying to say is that by getting other
>>> distros to package systemd, other distros will help RedHat to find and fix
>>> the problems systemd is causing.
>>
>> Exactly this.
>>
>>
> 
> Ah, a definition of "getting" that I was heretofore unfamiliar with.
> 
> Obviously "getting" doesn't mean what I think it means, it means
> "forcing without giving the other party much of a choice in the matter
> by ripping out essential infrastructure and replacing it with something
> tuned to RedHat, and only RedHat's, needs."
> 
> Ok, I got it now. Thanks for clearing that up.

In theory, it's supposed to be an additional option when choosing an
init system, rather than forcing a wholesale switchover across the Linux
infrastructure.

If it weren't for the upstream udev behavior, that's probably what it
would still be. (Perhaps eudev will be a resolution to this, perhaps
not. Only time will tell.)

Apart from the issues around udev, I don't expect this to get in the way
a whole lot. Converting systemd unit files to classic init scripts
shouldn't prove to be difficult to largely automate.

Getting systemic race issues fixed is probably going to be a good thing.
Getting daemon writers to architect their software in ways that survive
parallel booting will probably be a good thing. Code quality outside of
systemd *should* ultimately improve as a result of all this...but it's a
valid question whether or not the things being fixed would be worth the
effort if the new parallel boot agents hadn't begun taking hold.

On the other hand, it's equally valid to note that, with SMP
architectures becoming pervasive, it was only a matter of time before
traditionally-serial systems would be pressured into taking advantage of
them.

This too, shall pass.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: udev blocks systemd etc

[Michael Mol]

On 03/28/2013 12:28 AM, Grant Edwards wrote:
> On 2013-03-27, Michael Mol  wrote:
> 
>> The case for systemd is twofold:
>>
>> 1) Boot-to-desktop session management by one tool.
> 
> Ah, the old "universal generic tool" approach.  I've seen a lot of
> money and time poured into black-hole projects with names containing
> words like universal and generic, so I don't really like the sound of
> that.  [Is that the right response for somebody who started using V7
> Unix on a PDP11?]

It has theoretical advantages. Avoiding an impedance mismatch makes
turn-key systems that much easier. (I expect that to apply to embedded
systems like phones and consumer network gear, but we'll see how it
plays out. RAM is cheap, and getting cheaper...I just configured a
Netgear router with 128MB of RAM...)


> 
>>(The same thing that launches your cron daemon is what launches
>>your favorite apps when you log in.)
> 
> The only app that runs when I log in is bash.  Then I usually start
> XFCE from the command line -- but not always.
> 
>> 2) Reduce the amount of CPU and RAM consumed when you're talking
>>about booting tens of thousands of instances simultaneously across
>>your entire infrastructure, or when your server instance might be
>>spun up and down six times over the course of a single day.
> 
> It sounds like systemd really isn't intended for the likes of me.

Indeed.

> 
>>> Are there people who reboot their machines every few minutes and
>>> therefore need to shave a few seconds off their boot time?
>>
>> On-demand server contexts, yes.
> 
> Thanks for the explanation -- I never would have guessed that's how
> the whole cloud thing worked.

"Private clouds" work the same way. As business penetration of cloud
services grow, I expect we'll see backlash as major outages occur.
Imagine if cyberbunker had attacked Google rather than Spamhaus earlier
this week. The scale of that attack reached the upper limit of what the
Internet's infrastructure is capable of carrying...nobody, not even
companies with dozens of data centers in a distributed architecture, can
ultimately bear that. Organizations which have grown comfortable in an
age of reliable Internet access and cheap cloud services are going to
discover they still have operational needs that must go on even without
network access.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: udev blocks systemd etc

[Michael Mol]

On 03/28/2013 03:51 AM, J. Roeleveld wrote:
> On Thu, March 28, 2013 07:59, Alan McKinnon wrote:
>> On 28/03/2013 04:56, Michael Mol wrote:
>>> On 03/27/2013 05:51 PM, Alan McKinnon wrote:
>>>> On 27/03/2013 22:41, Michael Mol wrote:
>>>>> The case for systemd is twofold:
>>>>
>>>> ...
>>>>
>>>>> 2) Reduce the amount of CPU and RAM consumed when you're talking about
>>>>> booting tens of thousands of instances simultaneously across your
>>>>> entire
>>>>> infrastructure, or when your server instance might be spun up and down
>>>>> six times over the course of a single day.
>>>>
>>>> I seems to me that this is rather a niche quite-specialized case
>>>> (albeit
>>>> a rather large instance of a niche case). In which case it would be
>>>> better implemented as Redhat MagicSauce for their cloud environment
>>>> where it would be exactly tuned to that case's need.
>>>
>>> But it's a great deal cheaper to convince volunteers and package
>>> maintainers to put in the time to build the necessary service files of
>>> their own accord. Add in the complexity of parallel boot, and you can
>>> induce upstream to fix their own race-driven bugs rather than have to
>>> pay for that development directly.
>>>
>>
>> I don't follow the thought stream here Michael.
>> It feels like there's a word or a sentence missing (it's just not
>> hanging together)
> 
> Alan, I think what Michael is trying to say is that by getting other
> distros to package systemd, other distros will help RedHat to find and fix
> the problems systemd is causing.

Exactly this.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: udev blocks systemd etc

[Michael Mol]

On 03/27/2013 05:51 PM, Alan McKinnon wrote:
> On 27/03/2013 22:41, Michael Mol wrote:
>> The case for systemd is twofold:
> 
> ...
> 
>> 2) Reduce the amount of CPU and RAM consumed when you're talking about
>> booting tens of thousands of instances simultaneously across your entire
>> infrastructure, or when your server instance might be spun up and down
>> six times over the course of a single day.
> 
> I seems to me that this is rather a niche quite-specialized case (albeit
> a rather large instance of a niche case). In which case it would be
> better implemented as Redhat MagicSauce for their cloud environment
> where it would be exactly tuned to that case's need.

But it's a great deal cheaper to convince volunteers and package
maintainers to put in the time to build the necessary service files of
their own accord. Add in the complexity of parallel boot, and you can
induce upstream to fix their own race-driven bugs rather than have to
pay for that development directly.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: udev blocks systemd etc

[Michael Mol]

On 03/27/2013 04:00 PM, Grant Edwards wrote:
> On 2013-03-27, Kevin Chadwick  wrote:
> 
>> The real drive behind systemd is enterprise cloud type computing for
>> Red Hat. The rest is snake oil and much of the features already exist
>> without systemd. With more snake oil of promises of faster boot up on a
>> portion of the code which is already fast and gains you maybe two
>> seconds.
> 
> I'm not trying to fan the flames: I'm genuinely confused...
> 
> I just don't get the whole "parallel startup for faster boot thing".
> Most of my machines just don't boot up often enough for a few seconds
> or even tens of seconds to matter at all.

With cloud-based computing, you don't have a bunch of servers running,
waiting to received requests.

Instead, you have is a bunch of idle hardware, waiting to have pre-built
system images spun up on them on-demand.

The faster those pre-built images can spin up, the faster they can serve
requests. The faster they can serve requests, the fewer mostly-idle
images need to be already running for immediate needs. Traffic on a web
service usually spins up gradually. In the middle of the night, it's
low, but it increases during certain hours and decreases during others.
(Even with things like social media, there's a gradual buildup of
resource demands, as it takes URLs a while to take fire and spread.)
Ultimately, if you can have just enough images running to manage
immediate demand plus a small burst margin, you can save on costs. If
demand eats into your burst, you spin up more instances until you're
below your burst margin again. If demand falls, you kill off the extra
instances.

The quicker the spin-up process, the more efficient the on-demand system
becomes, and the better the resource utilization (and value to the
person paying for the cloud services).

(Though, really, I'd think that the best way to handle this kind of load
would be a hibernate system with a sparse image for RAM, and driver
tweaks to allow hardware to swap out from underneath in the event of
hardware changes while asleep. Or handle things like MAC address
rewriting in the VM hypervisor.)

> 
> It seems to me that starting things in parallel would be inherintly
> much more difficult, bug-prone, and hard to troubleshoot.

Indeed.

> 
> Even on my laptop, which does get booted more than once every month or
> two, openrc is plenty fast enough.

The case for systemd is twofold:

1) Boot-to-desktop session management by one tool. (The same thing that
launches your cron daemon is what launches your favorite apps when you
log in.)
2) Reduce the amount of CPU and RAM consumed when you're talking about
booting tens of thousands of instances simultaneously across your entire
infrastructure, or when your server instance might be spun up and down
six times over the course of a single day.

> 
> Are there people who reboot their machines every few minutes and
> therefore need to shave a few seconds off their boot time?

On-demand server contexts, yes.

> 
> I can see how boot time matters for small embedded systems (routers,
> firewalls, etc.) that need to be up and running quickly after a power
> outage, but they're probably even less likely to be running systemd
> than desktops or servers.

Servers in cloud environments have one normal state: "Off". But when
they need to be "On", they need to get there hella quickly, or the
client is going to lose out on ad revenue when he starts getting a few
tens of thousands of visits per minute.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] udev blocks systemd etc

[Michael Mol]

On 03/27/2013 01:08 PM, Canek Peláez Valdés wrote:
> On Wed, Mar 27, 2013 at 9:38 AM, Jake Margason  wrote:
>> I ran away from Arch last year to get away from all this systemd stuff. I
>> hope that you guys will continue to support openrc for as long as possible.
> 
> Don't do top posting, please.
> 
>> One question though. why does everyone seem to be migrating towards systemd?
>> How is it superior? is openrc just a dead project is that why?
> 
> That's three questions ;)
> 
> 1. "why does everyone seem to be migrating towards systemd?"
> 
> Not everyone is migrating towards systemd (yet), but the trend is
> certainly that more and more distros switch to it or at least offer it
> as a first class alternative to whatever other init system they use.
> As for why, I think it's for two reasons: a) it works, b) upstream
> udev merged with systemd, and most distros just follow upstream.
> 
> 2. "How is it superior?"
> 
> Well, that's the pickle. If you are like me, then systemd it's
> superior to OpenRC basically in every single way. If you are one of
> the people that thinks that something called "the UNIX way" actually
> exists, or that "Linux/Gentoo is about choice", or that we should care
> about our *BSD cousins keeping up with us, then systemd is far
> inferior.
> 
> From a technical point of view (the quality of the code and the time
> it takes to fix bugs), I believe everyone (even Lennart's most fervent
> detractors) will agree that systemd is a superb piece of software. The
> problem is the philosophy behind it; if you agree with said
> philosophy, systemd is great. Otherwise, is a new fangled beast which
> goes against everything that UNIX stands for (whatever that means), "a
> solution for a problem no one has", and "fixing something that wasn't
> broken".
> 
> 3. "is openrc just a dead project is that why?"
> 
> Is not dead; it has new releases and stuff. Just not many features are
> implemented to it, and it has some pretty awkward bugs, some of them
> years old, like not being able to start services in parallel.
> 
> It's obviously better that SysV. From my point of view, that's not enough.
> 
> Hope it helps.
> 
> Regards.
> 

A nice, reasonably even-handed writeup. :)





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] udev blocks systemd etc

[Michael Mol]

On 03/27/2013 10:33 AM, Michael Mol wrote:
> On 03/27/2013 10:25 AM, Tanstaafl wrote:
>> Ok...
>>
>> So, what is this all about?
>>
>> Does all of this mean that udev is now going *completely* away,
>> *totally* replaced by systemd?
>>
>> If so, has there been any kind of formal announcement about this
>> *anywhere*??
> 
> Hold your horses.
> 
> The devs will work something out; systemd is not replacing the udev
> package for all users. For the moment, it's just replacing the udev
> package for users using systemd.
> 
> The problem at the moment is a spat between the systemd maintainer and
> the udev maintainer. They don't see eye to eye about which packages
> should be providing which files (and where), and there's also a serious
> miscommunication (and misinterpretation of historical communication)
> issue between the two of them at the moment. They're trying to get it
> worked out (via attempting cooperation or via arbitration, whatever is
> necessary), and things will settle down.
> 
> In the mean time, if I read the context right, this issue should only
> affect people who are using systemd. This shouldn't be affecting people
> who aren't using systemd.

(incidentally, to anyone who's following the issue, please correct me if
I'm wrong...)




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] udev blocks systemd etc

[Michael Mol]

On 03/27/2013 10:25 AM, Tanstaafl wrote:
> Ok...
> 
> So, what is this all about?
> 
> Does all of this mean that udev is now going *completely* away,
> *totally* replaced by systemd?
> 
> If so, has there been any kind of formal announcement about this
> *anywhere*??

Hold your horses.

The devs will work something out; systemd is not replacing the udev
package for all users. For the moment, it's just replacing the udev
package for users using systemd.

The problem at the moment is a spat between the systemd maintainer and
the udev maintainer. They don't see eye to eye about which packages
should be providing which files (and where), and there's also a serious
miscommunication (and misinterpretation of historical communication)
issue between the two of them at the moment. They're trying to get it
worked out (via attempting cooperation or via arbitration, whatever is
necessary), and things will settle down.

In the mean time, if I read the context right, this issue should only
affect people who are using systemd. This shouldn't be affecting people
who aren't using systemd.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Best whois client?

[Michael Mol]

On 03/26/2013 01:54 PM, Stroller wrote:
> Searching portage, I find there are quite a number of alternative whois 
> clients. 
> 
> I think I have always used net-misc/whois in the past I now notice that a BSD 
> whois is available, a "generic" and an advanced jwhois.
> 
> Presumably there are some differences between the functionality provided by 
> these packages, can anyone tell me which is the "best", please?
> 
> I use whois a lot for looking up the abuse address of a host, by IP address. 
> Primarily I'd like to get up-to-date and useful results from something `whois 
> 1.2.3.4 | grep -i abuse`.
> 
> TIA for any help,
> 
> Stroller.
> 
> 

FWIW, I'm using jwhois. I don't remember why I settled on that one over
a different whois client, though.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] OT: parental control software

[Michael Mol]

On 03/20/2013 07:04 AM, Neil Bothwick wrote:
> I'm looking for software that can be used to control a child's usage of
> the computer (not Internet filtering). At the very least it should be
> able to control length of login sessions and when the child is able to
> login. Ideally it would also be able to control access to programs, for
> example education programs can be used for a couple of hours but games
> for only 30 mins at a time (net control software can be used to deal with
> online versions). There are other situations where this sort of thing is
> useful, so it need not necessarily be a package aimed specifically at
> parental controls.
> 
> Timekpr looks the ideal candidate, except it hasn't had a release in
> over three years.
> 
> Any suggestions?

I've been studying Kerberos a great deal lately, and so that's naturally
where my mind went when I read this. Take the practicality of the idea
with a grain of salt. I also make no claims to know exactly how to
implement this for programs not already inherently kerberized.

You might use Kerberos to enforce access limits by associating services
with each thing you wish to control, giving the auth tickets a short
rollover period, and refusing to regrant after a ticket has been rolled
over enough times in one day.

That easily covers the question of "when the child is able to log in",
and could also work for "enforce the length of login sessions" if you're
able to use a thin client model, or put the user's profile on a
kerberized samba or nfs server. I don't know what mechanisms are
available to force clean shutdowns of user sessions, though; anything I
can think of risks data loss if apps haven't committed all open data to
storage yet.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] [OT] Time-lock USB stick

[Michael Mol]

On 03/20/2013 04:47 AM, Michael Hampicke wrote:
> Am 20.03.2013 03:58, schrieb Michael Mol:
>> Does anybody know of time lock flash drives?
>>
>> The scenario I'm looking at is to have a drive that's only accessible
>> for a certain amount of time after being powered on. It would hold
>> crypto keys in a server context.
>>
> 
> I am no expert on embedded systems, but couldn't you achieve something
> like this by using a small dev board with like an Atmel controller?
> Which you then program to act like an USB stick?
> 

We discussed using a simple RC timer to cut power to the device after a
certain amount of uptime, but if I pointed out that if we were spend the
time going to that trouble, we may as well go whole-hog and add built-in
encryption and make money off the thing.

I think the grab-data-and-eject solution is probably the best for our
purposes.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] [OT] Time-lock USB stick

[Michael Mol]

On 03/20/2013 12:23 AM, Michael Orlitzky wrote:
> On 03/19/2013 11:28 PM, Michael Mol wrote:
> 
>> Not so much. The idea would be that you could power cycle the
>> device to get access to it again. The device would be read for the
>> keys at system bootup, but then would shut itself off after a few
>> minutes to prevent the keys from being read from disk. (There's
>> still the risk of them being read from the memory of the process
>> using them, but that's slightly more difficult, and security is all
>> about raising the bar.)
> 
> 
> Eject the USB drive after five minutes? This raises the bar
> significantly, to "has tried to send the 'close CD tray' command to a
> USB stick before."

That's sick, wrong and beautiful. I love it. :)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] [OT] Time-lock USB stick

[Michael Mol]

On 03/19/2013 11:18 PM, William Kenworthy wrote:
> On 20/03/13 10:58, Michael Mol wrote:
>> Does anybody know of time lock flash drives?
>>
>> The scenario I'm looking at is to have a drive that's only accessible
>> for a certain amount of time after being powered on. It would hold
>> crypto keys in a server context.
>>
> Something like this?
> 
> http://www.tomshardware.com/reviews/USB-Flash-Drives,2003-6.html
> 
> It does sound like you want a "dongle" like autocad used (?) to use.
> 
> I think the real solution though would be some kind of check with a
> remote site that would expire the keys

Not so much. The idea would be that you could power cycle the device to
get access to it again. The device would be read for the keys at system
bootup, but then would shut itself off after a few minutes to prevent
the keys from being read from disk. (There's still the risk of them
being read from the memory of the process using them, but that's
slightly more difficult, and security is all about raising the bar.)




signature.asc
Description: OpenPGP digital signature

[gentoo-user] [OT] Time-lock USB stick

[Michael Mol]

Does anybody know of time lock flash drives?

The scenario I'm looking at is to have a drive that's only accessible
for a certain amount of time after being powered on. It would hold
crypto keys in a server context.



signature.asc
Description: OpenPGP digital signature

Re: [Bulk] Re: Email encodings (was Re: [gentoo-user] Gentoo speed comparison to other distros )

[Michael Mol]

On 03/19/2013 05:09 PM, Kevin Chadwick wrote:
>> If you're going to call me out for ignoring things, missing things or
>> simply not  knowing things, please highlight what it is. "the quote"
>> isn't very enlightening in this context. You have a nasty habit of
>> referencing things without inlining them or referencing them directly,
>> and this has gotten in the way of clear communication *multiple* times
>> over the last week.
>>
>>> I only wrote two lines and you still missed it  
>>
>> I respond to what's written in the email I'm replying to, because that's
>> what I've just read, and that's the context of the email.
>>
>>> never mind the examples I had given in my original mail that do not
>>> only apply to remote content and that you wrongly interpreted.  
>>
>> Honestly, I never expected you to be up in arms over being exposed to
>> HTML syntax.
>>
>> I presumed you were concerned about libpng, libjpeg, swf and gif.
> 
> As I clearly said both, but actually less so html. You seem to be under
> the impression Androids mail clients let you avoid all that but they do
> not. Talk about hitting your head against a brick wall.

I can't tell any more whether you're complaining about people sending
HTML, whether you're complaining about receiving HTML emails without
being able to avoid parsing them, or whether you're complaining about
other people receiving HTML emails and their being placed at risk of
parsing bugs as a result.

If you're complaining about other people sending HTML emails: OK, fine.
Politely point out to them that it's common courtesy not to send HTML
emails. PLONK them if you need to. But make it clear this is what you're
complaining about. I don't see the relevance of most of your arguments
if your complaint is with other people sending HTML messages.

If you're complaining about receiving HTML emails without being able to
avoid parsing them: You're clearly technical enough to implement some
solution to avoid it. One solution would be to grab the source of an
existing mail client and patch it to not handle the HTML parts. Another
solution would be to have your mail pass through a server which strips
messages of those parts, or modifies them in some way to make them safe.
Yet another solution would be to find a mail client which does this for
you. I see no reason to continue raging about the state of the mail
clients you use, if this is your argument.

If you're complaining about other people receiving HTML emails and their
being placed at risk of parsing bugs, then provide a solution (I
detailed a few in the above paragraph) and allow them to adopt it if
they wish.

If what you're complaining about isn't enumerated above, please try to
state it simply and clearly.

> 
>> I
>> presumed you were concerned about privacy concerns. Those are what most
>> people who gripe about HTML email security are concerned with.
> 
> That would be to do with scripts and remote content.
> 
> Remote content Is as you have said almost always switchable and so was
> not a concern/thought of mine but yes, what people shout about. Scripts,
> well with Googles love of javascript (for obvious tracking reasons) I
> wouldn't be too surprised if that is enabled without recourse on
> android email.

I'm pretty sure I've never seen JS in email. Traditionally, tracking is
done with image bugs. There's little to no point in using scripting in
emails. And given Google is pushing as fast as they can away from RSS
and toward Google+, I'm rather expecting them to look for ways to get
away from email and XMPP, too.

Further, most GMail users use the web interface; there's No Way In Hell
Google would allow mail-delivered code to be executed from within that
security context. That would be the fastlane to account hijacking.

This argument boils down to: "I don't trust Google, so I'd like to
suggest they would use JS in emails, because that's scary, too."





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Gentoo speed comparison to other distros

[Michael Mol]

On 03/18/2013 08:10 PM, Kevin Chadwick wrote:
> On Mon, 18 Mar 2013 19:28:04 -0400
> Michael Mol  wrote:
> 
>>>
>>> Even though it is from a DVD it can be updated just like standard
>>> linux. The problem is, if you run out of ram then things get killed.
>>>
>>>   
>>>> (Frankly, this sounds quite nice for kiosk environments.)  
>>>
>>> Could be if you have a good enough network connection for Linux
>>> kernel updates or cut it right down ;-)  
>>
>> Local gigabit is cheap, and a gigabit connection would transfer the
>> image in under a minute. A bit more, of course, if you've got an
>> overloaded server being slammed by ten or twenty machines.
>>
>> (I wonder if one can anycast TFTP on a local segment. Hm. I think you
>> could just barely pull it off, since you'd have resolved the layer 2
>> address for your syn packet, and that should stick with the
>> connection.)
> 
> Kiosks are notorious for having difficulty in getting to connections
> as there place is determined by other factors. Still it may make a good
> choice of OS except for reboot time.
> 

I was thinking POS-style setups in a makerspace I help with.


If I had to cope with wireless or cellular, and I was seriously
concerned about security on a budget, I'd use an internal USB stick with
a fuse diode to prevent further writing, or an SD card with a similar
fuse tripped. Expire on a schedule. Send updates as replacement data
devices.



signature.asc
Description: OpenPGP digital signature

Re: [Bulk] Re: Email encodings (was Re: [gentoo-user] Gentoo speed comparison to other distros )

[Michael Mol]

On 03/18/2013 08:05 PM, Kevin Chadwick wrote:
> On Mon, 18 Mar 2013 19:16:52 -0400 Michael Mol  
> wrote:
> 
>>> 
>>> On 03/18/2013 04:38 PM, Kevin Chadwick wrote:
>>>>> It can write but forces html onto users,
>>> 
>>> You seem to miss some of the details.
>> 
>> About that. See the attachment. It's a screenshot of the setting in
>> K-9 where you can select composition methods. I took the screenshot
>> on my own phone. (And then ran it through pngcrush -brute in
>> deference to ML bandwidth...)
> 
> I knew that perfectly well??

You say 'It can write but forces html onto users'. So I pointed out
that, no, it doesn't.

So I take it you're complaining that *other peoples'* HTML clients force
HTML on you. That's a complete and total abdication of responsibility on
your part!

You can ignore these people if you wish. You can ignore the HTML parts
of emails if you wish. You can defang incoming emails if you wish. You
have no obligation to do any more than the minimum required for you to
selectively ignore emails with data you don't want.

> 
> You even missed the quote?

If you're going to call me out for ignoring things, missing things or
simply not  knowing things, please highlight what it is. "the quote"
isn't very enlightening in this context. You have a nasty habit of
referencing things without inlining them or referencing them directly,
and this has gotten in the way of clear communication *multiple* times
over the last week.

> I only wrote two lines and you still missed it

I respond to what's written in the email I'm replying to, because that's
what I've just read, and that's the context of the email.

> never mind the examples I had given in my original mail that do not
> only apply to remote content and that you wrongly interpreted.

Honestly, I never expected you to be up in arms over being exposed to
HTML syntax.

I presumed you were concerned about libpng, libjpeg, swf and gif. I
presumed you were concerned about privacy concerns. Those are what most
people who gripe about HTML email security are concerned with.

Being concerned with HTML syntax is a new one.

Being angry with mail clients for allowing people to send emails you
don't want to read? That'd ridiculous.

> 
> There is a security saying.
> 
> Assumption is the mother of all f
> 

Try including more context, and I won't have to assume as much or as often.



signature.asc
Description: OpenPGP digital signature

Re: [Bulk] Re: Email encodings (was Re: [gentoo-user] Gentoo speed comparison to other distros )

[Michael Mol]

On 03/18/2013 08:15 PM, Kevin Chadwick wrote:
> On Mon, 18 Mar 2013 23:38:11 +
> Neil Bothwick  wrote:
> 
 K9 Mail can do both plain text and bottom posting.
 Both set in Account settings/Sending mail.
>>>
>>> It can write but forces html onto users, which potentially includes
>>> jpg exploits, png exploits, html exploits, script exploits, font
>>> exploits...  
>>
>> What are you talking about? K9 forces HTML on no one, it sends plain
>> text if you set it to do so.
>>
> 
> If you receive a html email you have no choice but to execute code to
> handle as per my above examples.

Either you ignored what I said about being able to disable loading
remote content and being able to disable showing inline rich content, or
you're seriously concerned about HTML parser vulnerabilities.

If that's the case, set up a defanging filter for your email.

> 
>>> Having knocked Android, I haven't found the time to try the latest
>>> native email app. I'm not expecting a no html option but I'm pretty
>>> sure it will have some major pluses over k9mail, which was a trade
>>> of good for bad on Gingerbread.  
>>
>> K9 is not Android, any more than yourfavouriteemailer is Linux. It is
>> a program that runs on Android. As for being less capable than the
>> native app, the opposite is the case as it is based on the code from
>> the native app, but actively developed.
> 
> Googles mail is part of android and they do maintain it. I maintain
> that while k9 has some improvements it also breaks things and I guess
> would have not seen light without Googles initial efforts.

I'm really not sure what Google's native client (or K9) breaks. I use K9
because I require GPG support for communicating with one of my clients.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Gentoo speed comparison to other distros

[Michael Mol]

On 03/18/2013 05:38 PM, Kevin Chadwick wrote:
>>> 
>>> It's one of Blueness projects based on Hardened Gentoo. It loads
>>> into ram at boot (you need something like 4 gig of ram) which
>>> takes ages from dvd but could be from an ssd/hdd (defeating half
>>> the point without a ro switch though). It can update from the net
>>> once booted too.
>>> 
>>> Once done everythings in ram so firefox can literally pop up like
>>> a web advert upon execution.
>>> 
>> 
>> In other words, it's a distribution designed to not allow
>> persistent storage that might possibly be poisoned,
> 
> Not really, that is one benefit, but don't forget that BIOS, HDD or
> Video card firmware could have been altered.

Sure.

> 
> The main goals are reliability and leave no trace elements but it
> does have some added tamper ensurance yes.
> 
> I didn't spell it out because you should check the site to see all
> the details and would be bound to get it a little wrong without
> checking myself.
> 
>> and instead get much of its security-conscious code updated over
>> the network.
>> 
> 
> Security conscious code??? What do you mean? That says to me things 
> like PAX brute force protection??

I mean everything that gets updated more frequently owing to its being a
high-profile target in security contexts. Web browsers. Mail clients.
Listening daemons.

Having a static image that you need to update every time you boot is a
bit like plugging in an unpatched Windows machine that you need to run
updates on...every time you boot. It's a tad silly in that respect.

> 
> Even though it is from a DVD it can be updated just like standard
> linux. The problem is, if you run out of ram then things get killed.
> 
> 
>> (Frankly, this sounds quite nice for kiosk environments.)
> 
> Could be if you have a good enough network connection for Linux
> kernel updates or cut it right down ;-)

Local gigabit is cheap, and a gigabit connection would transfer the
image in under a minute. A bit more, of course, if you've got an
overloaded server being slammed by ten or twenty machines.

(I wonder if one can anycast TFTP on a local segment. Hm. I think you
could just barely pull it off, since you'd have resolved the layer 2
address for your syn packet, and that should stick with the connection.)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Gentoo speed comparison to other distros

[Michael Mol]

On 03/18/2013 04:21 PM, Kevin Chadwick wrote:
>> On 15 March 2013, at 17:32, Kevin Chadwick wrote:
>>>
>>> If you use the Gentoo hardened Tinfoil Linux you will need lots of ram
>>> and wait ages to boot but firefox will just pop up.  
>>
>> I'm sorry, I don't understand this statement. Could you possibly explain, 
>> please?
> 
> It's one of Blueness projects based on Hardened Gentoo. It loads into
> ram at boot (you need something like 4 gig of ram) which takes ages
> from dvd but could be from an ssd/hdd (defeating half the point
> without a ro switch though). It can update from the net once booted too.
> 
> Once done everythings in ram so firefox can literally pop up like a
> web advert upon execution.
> 

In other words, it's a distribution designed to not allow persistent
storage that might possibly be poisoned, and instead get much of its
security-conscious code updated over the network.

The "just pops up" being referred to simply comes from everything being
loaded into the kernel file cache before you can do anything with the
system.

(Frankly, this sounds quite nice for kiosk environments.)



signature.asc
Description: OpenPGP digital signature

Re: [Bulk] Re: Email encodings (was Re: [gentoo-user] Gentoo speed comparison to other distros )

[Michael Mol]

On 03/18/2013 04:38 PM, Kevin Chadwick wrote:
>>> Wait, K9 Mail doesn't have a plain text option?
>>>
>>> Perhaps I shouldn't be surprised, as I am also unable to comprehend why K9 
>>> might enforce top-posting on replies.  
>>
>> K9 Mail can do both plain text and bottom posting.
>> Both set in Account settings/Sending mail.
> 
> It can write but forces html onto users, which potentially includes jpg
> exploits, png exploits, html exploits, script exploits, font exploits...
> 
> And before you say anything. For what benefit, annoying ads from
> paypal. I am quite capable of opening a browser and deciding which
> domains *I* trust??
> 
> Google's network fell into this trap and banned Windows, but did they
> fix the real problem or just raise the bar a little (though I expect
> they took other unreleased measures that would be more interesting)?
> 
> Would be even worse on Iphones where webkit is forced and so as old as
> the rom image. Rom cycle time is a major reason why even on cyanogenmod
> I use firefox over the chrome package which is ancient.
> 
> Of course on Apple laptops even, Safari's webkit is sometimes months old
> anywhow.
> 
> Having knocked Android, I haven't found the time to try the latest
> native email app. I'm not expecting a no html option but I'm pretty
> sure it will have some major pluses over k9mail, which was a trade of
> good for bad on Gingerbread.
> 

I don't know what mail client you use (I suppose I could check your
headers), but *every* mail client I've used disables loading remote
content by default.

Further, you're ranting about users being "forced" to send email with
HTML, intimating that this means they'll send exploit-laden messages to
their recipients. That's patently silly; the people "forced" to send
HTML emails aren't going to be sending exploits. That's like suggesting
that people forced to drive to work are forced to commit vehicular
manslaughter...

It's the recipient of the email who has the burden of remaining secure,
and this is possible largely through simply disabling loading rich media
by default. Again, most mail clients disable loading remote media by
default, and most I've used support disabling packaged media as well.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] HTML editor WYSIWYG

[Michael Mol]

On 03/16/2013 11:39 PM, Joseph wrote:
> On 03/16/13 23:10, Michael Mol wrote:
>> On 03/16/2013 11:00 PM, Joseph wrote:
>>> Any recommendation for HTML editor Graphical.
>>> I've tried to use Open Office but it not user friendly.
>>
>> I used Bluefish...around a decade ago. But it's in Portage.
>>
> 
> Not user friendly either.
> 

Define "user-friendly". When I used Bluefish, I recalled it being
similar to Netscape Navigator Gold's bundled HTML editor...which is to
say it supported editing individual pages only, and had no concept of
JavaScript, JScript, VBScript or CSS.

Better than define "user-friendly"...how about describing what you're
trying to do? How large a project is this?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] HTML editor WYSIWYG

[Michael Mol]

On 03/16/2013 11:00 PM, Joseph wrote:
> Any recommendation for HTML editor Graphical.
> I've tried to use Open Office but it not user friendly.

I used Bluefish...around a decade ago. But it's in Portage.



signature.asc
Description: OpenPGP digital signature

Re: [Bulk] Re: Email encodings (was Re: [gentoo-user] Gentoo speed comparison to other distros )

[Michael Mol]

On 03/15/2013 04:34 PM, Mark David Dumlao wrote:
> On 03/16/2013 04:06 AM, Mick wrote:
>> On Friday 15 Mar 2013 17:36:48 Kevin Chadwick wrote:
> From the headers of his email:
>
> Subject: Re: [gentoo-user] Gentoo speed comparison to other distros
> References: <51418728.7020...@gmail.com>
> In-Reply-To: <51418728.7020...@gmail.com>
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
>
> It's perfectly compliant. You may want to correct your mail client to
> understand HTML.
>
> (Admittedly, it's unusual to see email clients send *only* text/html,
> rather than a multipart message with two different encodings.)
 ROFL. It's called "me wrestling with thunderbird to try to remove html
 formatting but failing".
>>> Compulsory html annoys me on Android (If only you could have proper
>>> programs like Nokias N9 had claws)
>>>
>>> Claws would mean you needn't bother and still have html to text by
>>> default and can even enable html plugins if desired (right way around).
>>
>> I understand that you can specify what sort of mail format you want to send 
>> per email recipient, including of course , but 
>> I 
>> don't have T'bird installed to check:
>>
>>   http://kb.mozillazine.org/Plain_text_e-mail_(Thunderbird)
>>
>> HTH.
> 
> I know about that. But it fails to work on compose windows opened by the
> thunderbird conversations plugin. Quotes there seem to be hard-quoted as
> HTML and no amount of fiddling converts those into plaintext quotes.

Reply created from conversation view in Thunderbird.

(Though I've got some configuration item set somewhere to only send in
plaintext; Enigmail complains that text/html emails don't always work
right with PGP signing.)



signature.asc
Description: OpenPGP digital signature

Email encodings (was Re: [gentoo-user] Gentoo speed comparison to other distros )

[Michael Mol]

On 03/14/2013 11:17 AM, Bruce Hill wrote:
> On Thu, Mar 14, 2013 at 07:29:54PM +0800, Mark David Dumlao wrote:
>> 
>>   
>> >   http-equiv="Content-Type">
>>   
>>   
>> On 03/14/2013 04:15 PM, Dale wrote:
>> 
>> 
>>   Also, I read that Nasdaq runs a modified version of 
>> Gentoo.  Do any
>> other large corps run it that we know of? 
>>
>> 
>> 
>> What exactly does it mean to run a "modified version of Gentoo"?
>> Don't we all? ;)
>>   
>> 
> 
> What kind of crap email do you call that ^^^ ?
> 

From the headers of his email:

Subject: Re: [gentoo-user] Gentoo speed comparison to other distros
References: <51418728.7020...@gmail.com>
In-Reply-To: <51418728.7020...@gmail.com>
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

It's perfectly compliant. You may want to correct your mail client to
understand HTML.

(Admittedly, it's unusual to see email clients send *only* text/html,
rather than a multipart message with two different encodings.)



signature.asc
Description: OpenPGP digital signature

Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?

[Michael Mol]

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-misc&m=129666298029771&w=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-misc&m=124536321827774&w=2

True enough. And since we're there, it's critical that people learn how
to handle their problems.

> 
>>> 
>>> http://marc.info/?l=openbsd-misc&m=135325826302392&w=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-

Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?

[Michael Mol]

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-misc&m=135325641430178&w=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* u

Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?

[Michael Mol]

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 Q&A 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

Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?

[Michael Mol]

On 03/11/2013 12:00 AM, 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.

They're two sides of the same coin. If NAT wasn't such a problem,
layering RFC1918 address space would solve most of the address space
problems. The address space crunch remains a technical problem largely
because NAT can't solve it to completion.

NAT forces a distinction between 'client' and 'server', breaking the
'peer' nature of the network. This isn't some hippy egalitarian thing,
it means I can't trivially tell my VPS to connect to a backup target on
a different network without setting up either a tunnel or a port
forward. With IPv6, doing this is so brain-dead easy I never want to be
without it again. Once you've experienced IPv6 and appropriate network
firewalls, along with the ease of connecting to your own machines from
anywhere you want without having to bounce through a third-party
management service like Teamviewer, you never want to go back. It's like
discovering you've been holding a pencil wrong all your life, or like
discovering a better way to tie your shoes; the solution is simple,
elegant and surprisingly productive. NAT is like tying your shoes wrong;
you don't know how much of a problem it is until you experience life
without it.

And even once you get people comfortable with deploying IPv6, they still
want to hold on to NAT; it's like a stubborn stain on their minds.

It's important to explain that NAT isn't a security measure. In order to
operate, it requires what amounts to a stateful firewall...but that
doesn't mean that a stateful firewall is difficult to obtain without
NAT. People have grown so accustomed to the presence of NAT and NAT's
inherent implications on inbound traffic that they wind up conflating
the two in their minds, making actual understanding of their network's
security that much more difficult to comprehend. So, yeah, NAT is evil.

Looking for privacy in your addresses? That's what privacy extensions
are for, and they're enabled by default on Windows and Ubuntu. (I
haven't looked on Gentoo...)

The only reasonably valid use case for NAT that I've seen is for dealing
with the question of multi-homing an office with two internet
connections. The idea is that you don't have to renumber your internal
network if you need to switch from your primary connection to your
backup connection (and you're being granted different IP ranges based on
which connection you're working with...so we're talking small business,
not BGP or multilink with the same ISP).

In those cases, I advocate application-layer gateways; chances are, if
you're investing in multi-homing your office, you probably already want
the kind of administrative power (and performance improvements) proxy
servers can offer you.

The IPv4 address crunch triggered the development of DNAT a couple
decades ago, and the silly thing persists in terrible ways when there
are simpler ways to handle things. (When I say 'simpler', I mean: Don't
break assumptions about basic network behavior such as 'don't mangle my
packets' or 'I can open a connection back to him when I have updates he
needs')





signature.asc
Description: OpenPGP digital signature

Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?

[Michael Mol]

On 03/10/2013 09:56 PM, Michael Orlitzky wrote:
> On 03/10/2013 06:00 PM, Michael Mol wrote:
>>>
>>> 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.
> 
> 
> This was a non-sequitur as far as I can tell, but I remember the
> amplification attack from a talk:
> 
>   http://vimeo.com/18279777 (video)
>   http://cr.yp.to/talks/2010.12.28/slides.pdf (slides)
> 
> It was a really good talk, however you feel about DJB.
> 
> 

Didn't watch the video, but I did read the slide deck. It's a good read,
even if I disagree with a number of key points, disagree with the tack
taken as a solution, and further think the presenter cherry-picked his
arguments, amplified inconsequential pieces of the problem space and
skipped over obvious problems with his approach. (Hm. I suspect I'm
formulating an opinion on DJB, and I didn't have one a couple hours
ago...) (That said, he does seem to know how to use slide decks properly!)


I believe Kevin's position is that, while I cited "secure your DNS" in
response to some of the arguments raised by a slide deck he linked to,
"securing your DNS" would likely involve using DNSSEC, which DJB argues
enable amplification attacks.



signature.asc
Description: OpenPGP digital signature

Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?

[Michael Mol]

On 03/10/2013 05:43 PM, Alan McKinnon wrote:
> On 10/03/2013 23:07, Michael Mol wrote:
>>> All those examples you give are much like a bunch of home machines 
>>>> sitting behind a NAT gateway onto the internet. That's actually OK
>>>> and I reckon that is the intended use of NAT.
>> I want to point out that that's only true if the home network has at
>> least one public IP. If you've got NAT 4x4, you're kinda screwed.
>>
>> (Alan will understand that, but for those unfamiliar with it, that
>> basically means that if your home router is given an RFC1918 address by
>> your ISP, port forwarding isn't going to do squat for you.)
> 
> 
> I'm getting images of NATted traffic being NATted. My head just exploded.

Yup. That's the state of small residential ISPs right now, and why it's
so critical to get IPv6 deployed.




signature.asc
Description: OpenPGP digital signature

Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?

[Michael Mol]

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!
>> 
> 
> 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!

> 
>> 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.

> 
> 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.

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 you've
already got serious security problems by way of a MITM opening.)

Then he turns around and dedicates two slides showing a DNS delegation
sequence...and then states in a single slide that DNSSEC has all the
same problems as HTTPSEC.

DNSSEC doesn't have the same problems as HTTPSEC, because almost *every*
recursive resolving DNS server (which is most of the DNS servers on the
Internet) employs caching.

> 
>> "An attacker can connect to an IPv4-only network, and forge IPv6 
>> Router Advertisement messages. (*)"
> 
>> Again, this depends on them being on the same layer 2 network 
>> segment.
> 
>> The same class of attacks would be possible for any IPv4 successor
>>  that implemented either RAs or DHCP.
> 
> Neither of which I use.

You're telling me you don't use DHCP? Seriously, that you statically
configure the IPv4 addresses of all the hosts on your network?

With one exception, I haven't personally seen a network configured in
that way since 1998! Certainly, every network has some hosts configured
statically, but virtually no network I've observed (and I've seen
private networks between 2 and 50 hosts, and commercial networks between
5 and 30k hosts) managed completely statically.

> 
> As I said we would be here all day and that link wasn't as good as 
> the one I was actually looking for.
> 
> local NAT done right is no problem and actually a good thing and I 
> have no issues playing games, running servers or anything else behind
> NAT.

See others' responses about port standardization, and abo

Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?

[Michael Mol]

On 03/09/2013 07:53 AM, Kevin Chadwick wrote:
>>>
>>> Lookup ipvshit
>>>
>>> I'll give you a hint.
>>>
>>> The guy who wrote most of the pf firewall that MAC OSX now uses as well
>>> as QNX, the latest version originating from OpenBSD and being far better
>>> than iptables has bought up lots of ipv4 just to stay away from ipvshit.
>>>   
>>
>> Tried searching for it. You're going to have to provide some useful
>> direct reference, because a basic search wasn't very illuminating.
> 
> Perhaps Google doesn't approve of swear words?!

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-misc&m=129666298029771&w=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.

> 
> http://marc.info/?l=openbsd-misc&m=135325826302392&w=2
> 

This email has absolutely no technical content whatsoever.



signature.asc
Description: OpenPGP digital signature

Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?

[Michael Mol]

On 03/09/2013 11:59 PM, Michael Orlitzky wrote:
> On 03/09/2013 08:42 PM, Walter Dnes wrote:
>> On Fri, Mar 08, 2013 at 07:41:13PM -0500, Michael Mol wrote
>>
>>> The trouble with NAT is that it destroys peer-to-peer protocols. The
>>> first was FTP in Active mode.
>>
>>   In its day, it was OK.  Nowadays, we use passive mode.  What's the
>> problem?
>>
> 
> It also doesn't work under NAT, it's just broken in the other direction.
> 
> 
>>> SIP has been heavily damaged as well.  Anyone who's used IRC is
>>> familiar with the problems NAT introduces to DCC.
>>
>>   Every ADSL router-modem I've run into recently has port-forwarding.
>>
>>> Anyone who's ever played video games online,...
>>
>>   A *CLIENT* that can't operate from behind NAT is totally brain-dead.
>>
> 
> But you must have one non-NATed "server" for anything to work. I assume
> that's what was meant by "it destroys peer-to-peer protocols." You have
> to draw an arbitrary distinction between machines that work together,
> "servers," and ones that don't, "clients."

Indeed.

> 
> The problem will become more and more apparent as ipv4 space dries up
> and everyone becomes a client. Although ISPs will be more than happy to
> sell you a useful connection, for a premium.

This has happened to a friend of mine...and he *can't* get a public IP
from his rural ISP.

> 
> Un-NATed addresses are like, type-O blood. Imagine how much better off
> we'd be if we could get everyone to switch their blood to type-O. Might
> be less painful than the ipv6 transition, too =)
> 
> 
>>> or who's tried hosting a Teamspeak or Ventrillo server, has had NAT
>>> get in their way as well.
>>
>>   Port-forwarding.
>>
> 
> Port forwarding can work, but only for one host when the ports are
> standardized. You can't forward e.g. port 443 to two hosts, so only one
> host behind the NAT can be accessible on 443.
> 
> If you're using your NAT as a firewall for one box, then who cares. But
> you can't put more than one machine behind it and have everything still
> work.

Since we've already run out of IPv4 addresses, port forwarding is
starting to fail even for that circumstance; if your ISP hands you an
RFC1918 address, you're screwed.




signature.asc
Description: OpenPGP digital signature

Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?

[Michael Mol]

On 03/10/2013 12:19 AM, Alan McKinnon wrote:
> On 10/03/2013 03:42, Walter Dnes wrote:
>> On Fri, Mar 08, 2013 at 07:41:13PM -0500, Michael Mol wrote
>> 
>>> The trouble with NAT is that it destroys peer-to-peer protocols.
>>> The first was FTP in Active mode.
>> 
>> In its day, it was OK.  Nowadays, we use passive mode.  What's the 
>> problem?
>> 
>>> SIP has been heavily damaged as well.  Anyone who's used IRC is 
>>> familiar with the problems NAT introduces to DCC.
>> 
>> Every ADSL router-modem I've run into recently has
>> port-forwarding.
>> 
>>> Anyone who's ever played video games online,...
>> 
>> A *CLIENT* that can't operate from behind NAT is totally
>> brain-dead.
>> 
>>> or who's tried hosting a Teamspeak or Ventrillo server, has had
>>> NAT get in their way as well.
>> 
>> Port-forwarding.
> 
> 
> All those examples you give are much like a bunch of home machines 
> sitting behind a NAT gateway onto the internet. That's actually OK
> and I reckon that is the intended use of NAT.

I want to point out that that's only true if the home network has at
least one public IP. If you've got NAT 4x4, you're kinda screwed.

(Alan will understand that, but for those unfamiliar with it, that
basically means that if your home router is given an RFC1918 address by
your ISP, port forwarding isn't going to do squat for you.)

I've got a friend in a rural area who can't get a publicly-routable
address. To access his home network from work, he rents a VPS and sets
up a static tunnel.

Such are the evils of NAT.

> Personally, I'd prefer all of my machines to have a public address
> but there's no chance in hell my NetOps colleagues are giving me that
> with my DSL connection.

Well, with IPv6, they're supposed to. ^^

> 
> We have any years of experience now with consumer connections and
> the users that use them, these guys mostly can't admin a machine to
> save their lives, so NAT in their case is a good thing on balance.

There's nothing NAT really offers them that having a default simple
firewall on their network gateway wouldn't solve.

If inbound traffic is part of an established or related connection,
accept it. Otherwise, reject it by default. That's all the security
benefit NAT accomplishes, albeit without mangling any packets.

> 
> The true evil of NAT comes about when some clown starts implementing
> it on the network itself. I'm in city X, we have a large office in
> city Y, and most of the traffic Y->X goes through a *router* doing
> NAT. No-one knows anymore why this was originally done but we all
> know what it will take to undo it. To get our backend systems to work
> for client in city Y I have to put in the cursed "any any" firewall
> rules, and that sends our Risk fellows ballistic for good reason. But
> I have no choice, the network design essentially discarded all
> information as to who the client is, so now I must allow all of
> them.
> 
> Any real-life network that grew organically over several years is
> always going to be rife with examples of fuck ups like this, always
> done in the name of expediency. I have lots of such examples, the
> above is only the first that came to mind.
> 
> So whereas NAT behind a home router for IPv4 is good, in almost
> every other usage I've seen it is bad and really just a case of a
> solution used in places it never ever belonged.

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. (It's unfortunate we never got DHCP-PD for IPv4; that would solve a
number of problems I've seen and foresee with small-business IPv4
networks both pre- and post-crunch.)




signature.asc
Description: OpenPGP digital signature

Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?

[Michael Mol]

On 03/08/2013 07:50 PM, Kevin Chadwick wrote:
>> Unfortunately, your logic is flawed.
>>
>> Where would you put the additional bits of address?
>>
>> That would involve rewriting the IP Header.
>>
> 
> Your assumption that I do not know that is flawed. I did a review of
> ipv6 before it was released and determined ipv4 to be superior then.
> That was before I was shown some of the bad sides more recently.
> 
>> And while we're at it, why not *totally* remake IP based on decades of
>> observation & experience?
>>
> 
> Who's observations and who's experience. Not everyones that's for damn
> sure.

This is why the IETF exists, to allow vendors and engineers with field
knowledge to argue and debate until they come up with something that
most of them can agree on. IPv6 is what came out of that process.

I'm not going to say IPv6 doesn't have flaws...but it's certainly a lot
better than IPv4, and features it adds (even beyond address space
expansion) are very nice.

> 
>> Hence, IPv6.
> 
> Lookup ipvshit
> 
> I'll give you a hint.
> 
> The guy who wrote most of the pf firewall that MAC OSX now uses as well
> as QNX, the latest version originating from OpenBSD and being far better
> than iptables has bought up lots of ipv4 just to stay away from ipvshit.
> 

Tried searching for it. You're going to have to provide some useful
direct reference, because a basic search wasn't very illuminating.



signature.asc
Description: OpenPGP digital signature

Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?

[Michael Mol]

On 03/08/2013 07:45 PM, Kevin Chadwick wrote:
>>> What would have been best, could have been done years ago and
>>> not cost lots of money and even more in security breaches and
>>> what I meant by ipv5 and would still be better to switch to even
>>> today with everyone being happy to switch to it is simply ipv4
>>> with more bits for address space.
>> 
>> This should be FAQ entry zero for the IPV6 FAQ... *NO* you can 
>> *NOT* add more bits to IPV4, and still have it backwards 
>> compatable.  It won't work... period... end of story.  Every piece 
>> of hardware and software that deals with IPV4 has the concept of 32
>> bits *HARD-CODED* into it. Switching over to IPV4-extended would be
>> just as painfull as switching over to IPV6.
> 
> No it would not, the headers would be different. All the hardware 
> would have already updated because there would be no bad sides and
> it would have been released something like 15 years ago. But lets
> not discuss them as we would be here for an eternity and there are 
> already whole websites dedicated to just that.

I don't know, you just dropped the 2-3 most trollish anti-IPv6 posts
I've ever seen.


> 
> I re-iterate it would be worth hardware not being backwards 
> compatible again to go to ipv4 with large address space today.

"IPv4 with large address space" would have taken just as long to deploy;
it's the hardware support that's held us back the most.

> 
> http://www.hackingipv6networks.com/past-trainings/hip2011-hacking-ipv6-networks.pdf
>
> That's just on security. There's a whole bad side to it's
> functionality too.
> 

Let's discuss security. I'll walk through the slide deck.

"We have much less experience with IPv6 than with IPv4"

That's a meaningless statement...

"IPv6 implementations are much less mature than their IPv4 counterparts."

Only in hardware Software has been much better. Windows has had full
IPv6 support since Vista. Linux has
had full IPv6 support for a few years, including IPSec. The software
implementations are written...the stuff that's still arriving is
feature-add.

Offload engines and managed switches haven't switched over because
clients were more interested in putting off a transition (the same
transition you'd have to go through for IPv4 with extended address
space) than paying for the upgrades. This would have happened with any
IPv4 replacement.

"Security products (firewalls, NIDS, etc.) have less support for IPv6
than for
IPv4"

Dedicated commercial products, yes. General-purpose products? Like I
said, Windows Vista made IPv6 a first-class protocol, including firewall
support. Linux's implementation is a bit quirky. I don't care for the
separation between iptables and ip6tables; I think people tend to write
an iptables script and forget to set up a firewall of any kind for IPv6.
Most of the builder tools (i.e. fwbuilder), require seperate setup
between the two, too.

That's why I use sanewall (formerly firehol); defined rules apply to
both IPv4 and IPv6.

"The complexity of the resulting network will greatly increase during
the transition/co-existence period:"

Yes, and that would apply to any transition period.

"Lack of trained human resources"

That's why people like me go out and do training sessions. (I'll be at
Penguicon again this year, if anyone else was thinking about going...)
That's why Hurricane Electric offers free online certification programs.

Regarding flow labels:

"Currently unused by many stacks – others use it improperly"

Honestly, I don't know about this. It's not something most people will
need to work with.

"Might be leveraged to perform “dumb” (stealth) address scans"

I don't understand the relevance; you get the same information by
observing the packet flow without the flow label.

"Might be leveraged to perform Denial of Service attacks"

So might absolutely anything.

Regarding hop limit:

"Could be leveraged for Detecting the Operating System of a remote node"

So can IPv4's TTL, which it's analogous to.

"Could be leveraged for Fingerprinting a remote physical device"

So can IPv4's TTL, which it's analogous to.

"Could be leveraged for Locating a node in the network topology"

tcptraceroute does this with IPv4 TTLs. And traceroute has been doing
this with IPV4's ICMP echo for decades.

"Could be leveraged for Evading Network Intrusion Detection Systems (NIDS)"

Just like IPv4 TTL.

"Could be leveraged for Reducing the attack exposure of some
hosts/applications"

Not sure what's being said here, but we're talking about a feature
directly analogous to IPv4 TTL.

(skipping the remainder of the section, as there's nothing in there
that's bad that's unique to IPv6)

(skipping the next several sections, as they're just general technical
training material, and don't discuss security implications)

Re Fragmentation security implications that are different from IPv4:

"The Identification field is much larger: chances of “IP ID collisions”
are reduced"

Good thing.

"Note: Overlapping fragments have b

Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?

[Michael Mol]

On 03/08/2013 07:13 PM, Walter Dnes wrote:
> On Fri, Mar 08, 2013 at 09:49:23PM +, Kevin Chadwick wrote
> 
>> What would have been best, could have been done years ago and not cost
>> lots of money and even more in security breaches and what I meant by
>> ipv5 and would still be better to switch to even today with everyone
>> being happy to switch to it is simply ipv4 with more bits for address
>> space.
> 
>   This should be FAQ entry zero for the IPV6 FAQ... *NO* you can *NOT*
> add more bits to IPV4, and still have it backwards compatable.  It won't
> work... period... end of story.  Every piece of hardware and software
> that deals with IPV4 has the concept of 32 bits *HARD-CODED* into it.
> Switching over to IPV4-extended would be just as painfull as switching
> over to IPV6.
> 
>   We will be running out of IPV4 address space shortly so we do need to
> upgrade.  Having said that, I don't understand all the hate for NAT.  At
> the risk of being called an elitist, I'll say that 95% of average
> internet users have no business running servers; heck many of them can't
> even keep *CLIENTS* properly secured.  If IPV6-NAT in my home causes me
> any problem, that's my problem.
> 

The trouble with NAT is that it destroys peer-to-peer protocols. The
first was FTP in Active mode. SIP has been heavily damaged as well.
Anyone who's used IRC is familiar with the problems NAT introduces to
DCC. Anyone who's ever played video games online, or who's tried hosting
a Teamspeak or Ventrillo server, has had NAT get in their way as well.

Seriously, why should my voice packets have to travel across three or
more states in order to bounce through Google Voice servers, if I'm
talking to my wife on her laptop in the next city over?





signature.asc
Description: OpenPGP digital signature

Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?

[Michael Mol]

On 03/08/2013 02:50 PM, Kevin Chadwick wrote:
>> 1. The craziness of trying to conserve IPv4 space
>> 2. NAT. Finally, a good solid techical reason to make NAT just go away
>> and stay away. Permanently. Forever.
> 
> It's a great shame that isn't all it fixed (ipv5), then your job
> wouldn't have been so hard and there wouldn't be any reason for many of
> us to cling to ipv4 of which there are many strong reasons that are far
> far worse than NAT.
> 
> 

IPv5 never really existed.

http://www.oreillynet.com/onlamp/blog/2003/06/what_ever_happened_to_ipv5.html



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] /etc/hosts include file?

[Michael Mol]

On 03/08/2013 03:32 AM, Alan McKinnon wrote:
> On 08/03/2013 02:29, Michael Mol wrote:
>> On 03/07/2013 05:24 PM, Alan McKinnon wrote:
>>> Anyone know if there's a way to get /etc/hosts to support the notion of
>>> an include file? I did my homework and found nothing, maybe someone else
>>> knows more.
>>>
>>> I really do need this, I have an app that discovers things on the
>>> network and knows their address. This makes it's automated way into DNS
>>> but takes a few days, and another app needs to use the fqdn right now.
>>> So /etc/hosts is the way to go for the interim three days.
>>>
>>> I've worked around it by creating /etc/hosts.d/ containing a header and
>>> a data file. cat the two and redirect to /etc/hosts.d/hosts and the real
>>> hosts file is a symlink to that. It's a sub-directory as none of these
>>> apps run as root and only root can modiy the real hosts file.
>>>
>>> This works well enough, but a supported include mechanism would make
>>> life so much simpler, not to mention easier for my colleagues to
>>> understand what the blazes I set up :-)
>>
>> No, there's not an "include" directive.
>>
>> There are, however, two other ways to get hostnames recognized.
>>
>> The first is /etc/resolv.conf . You can point your host at a local DNS
>> server which is aware of the discovered hosts, and which forwards the
>> rest of the queries. (This is how Samba 4's internal DNS server
>> operates; anything it knows, it responds to. Everything else, it forwards.)
>>
>> Read the manpage for resolv.conf...there's a lot of stuff in there
>> you'll want to know as you start coping with IPv6. (And some useful
>> stuff if you want to favor a particular IP range...)
> 
> And the day started off so well. Then you had to come along and mention
> IPv6 :-)
> 
> IPv6 is wonderfully easy to use client-side and reasonably easy to plug
> into an existing network (the routers mostly know what to do already).
> The fun starts when you need to write an app that tracks and does range
> allocations at ISP scale, all while keeping the PTRs in line too. Sadly
> for me, my team works in that area and such a magic app is one of our
> deliverables

My mouth is watering...

> 
> One day when I've climbed down off the walls and my fingernails have
> grown back, I might be up to relating what it is taking to get that
> done :-)

I don't suppose you knew I'm a huge IPv6 advocate, and travel around my
state giving free training sessions...

I would absolutely love to hear about the problems you're facing.
Further, I'd love to help you get past them...and can put you in touch
with experts who might also be able to help.


> 
>>
>> The second is /etc/nsswitch.conf . nsswitch.conf is how you inject
>> samba-discovered, NIS-offered -- or whatever provider you care to inject
>> -- hostname databases into the system resolver. You could have it query
>> your provided database first, moving on to other sources if your
>> provided database doesn't have what you're looking for. (I'm actually
>> kinda surprised avahi doesn't come with an nss plugin...)
> 
> One day I should read nsswitch's man page completely. I never needed to
> know more than "dns files" for the hosts directives and that shadow does
> user. All those other lookup schemes are things I never use.

I've never mucked with NIS, but I muck with samba from time to time.

If you're already in a developer context, I'd suggest writing an NSS
plugin the system resolver can check on. That's the angle I'd take in
your circumstance.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] /etc/hosts include file?

[Michael Mol]

On 03/07/2013 05:24 PM, Alan McKinnon wrote:
> Anyone know if there's a way to get /etc/hosts to support the notion of
> an include file? I did my homework and found nothing, maybe someone else
> knows more.
> 
> I really do need this, I have an app that discovers things on the
> network and knows their address. This makes it's automated way into DNS
> but takes a few days, and another app needs to use the fqdn right now.
> So /etc/hosts is the way to go for the interim three days.
> 
> I've worked around it by creating /etc/hosts.d/ containing a header and
> a data file. cat the two and redirect to /etc/hosts.d/hosts and the real
> hosts file is a symlink to that. It's a sub-directory as none of these
> apps run as root and only root can modiy the real hosts file.
> 
> This works well enough, but a supported include mechanism would make
> life so much simpler, not to mention easier for my colleagues to
> understand what the blazes I set up :-)

No, there's not an "include" directive.

There are, however, two other ways to get hostnames recognized.

The first is /etc/resolv.conf . You can point your host at a local DNS
server which is aware of the discovered hosts, and which forwards the
rest of the queries. (This is how Samba 4's internal DNS server
operates; anything it knows, it responds to. Everything else, it forwards.)

Read the manpage for resolv.conf...there's a lot of stuff in there
you'll want to know as you start coping with IPv6. (And some useful
stuff if you want to favor a particular IP range...)

The second is /etc/nsswitch.conf . nsswitch.conf is how you inject
samba-discovered, NIS-offered -- or whatever provider you care to inject
-- hostname databases into the system resolver. You could have it query
your provided database first, moving on to other sources if your
provided database doesn't have what you're looking for. (I'm actually
kinda surprised avahi doesn't come with an nss plugin...)




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] /etc/hosts include file?

[Michael Mol]

On Mar 7, 2013 5:28 PM, "Alan McKinnon"  wrote:
>
> Anyone know if there's a way to get /etc/hosts to support the notion of
> an include file? I did my homework and found nothing, maybe someone else
> knows more.
>
> I really do need this, I have an app that discovers things on the
> network and knows their address. This makes it's automated way into DNS
> but takes a few days, and another app needs to use the fqdn right now.
> So /etc/hosts is the way to go for the interim three days.
>
> I've worked around it by creating /etc/hosts.d/ containing a header and
> a data file. cat the two and redirect to /etc/hosts.d/hosts and the real
> hosts file is a symlink to that. It's a sub-directory as none of these
> apps run as root and only root can modiy the real hosts file.
>
> This works well enough, but a supported include mechanism would make
> life so much simpler, not to mention easier for my colleagues to
> understand what the blazes I set up :-)
>
>
>
> --
> Alan McKinnon
> alan.mckin...@gmail.com
>
>
>

See resolv.conf and nsswitch.conf

More details later...but nsswitch, at least, is how one can mix hosts, DNS,
NIS and winbind on the same box...

Re: [gentoo-user] {OT} RAM & apache MaxClients (rock & a hard place)

[Michael Mol]

On 03/07/2013 04:44 PM, Grant wrote:
>>> Thanks Michael, I think I will set up nginx to serve my images.  That
>>> should take a big load off apache.  Is nginx still beneficial when
>>> using the Worker MPM?
>>
>> It...depends?
>>
>> nginx in reverse caching proxy mode will simply serve up objects before
>> the httpd it's protecting has to deal with them. Whether the type of an
>> MPM makes a significant difference on nginx's value depends more on what
>> kind of work you are (or aren't) asking Apache to do. I really couldn't
>> answer that for you without knowing the details behind what you're
>> running on top of Apache.
> 
> OK, I think either nginx or Worker would help prevent MaxClients from
> being reached and using both of them would help even further.

If you're using mod_php, you cannot use MPM Worker. Just sayin. It's so
unsupported, they block each other in Portage.

> 
>>> Should I be OK with NGINX_MODULES_HTTP="" in /etc/make.conf if I'm
>>> only serving images?
> 
> Any Gentoo'ers running nginx like this?

Alan McKinnon remarked that he uses nginx in this capacity.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] {OT} RAM & apache MaxClients (rock & a hard place)

[Michael Mol]

On 03/07/2013 04:34 PM, Grant wrote:
>> Michael's proxy suggestion is excellent too - I use nginx for this
>> a lot. It's amazingly easy to set up, a complete breath of fresh
>> air after the gigantic do-all beast that is apache. Performance
>> depends a lot on what your sites actually do, if every page is
>> dynamic with changing content then a reverse proxy doesn't help
>> much. Only you know what your page content is like.
> 
> It sounds like having apache serve dynamic .html pages and nginx
> serve images on the same port means turning apache into a proxy for
> nginx which I'm hoping isn't too difficult.  Could this pose any
> problems for an ecommerce site?



> Changing completely from a user-facing apache to a user-facing nginx
> sounds fraught with peril.

Yet this is the way it's done. If you have apache serve as a proxy for
nginx, you gain absolutely *nothing*; every inbound connection still
takes Apache resources, and that's exactly what you need to introduce a
proxy to alleviate.

Think of it like phone lines. Let's say you're getting fifteen phone
calls an hour. It's too much. You hire a secretary named nginx to screen
your calls for you and handle the simple responses like "has he changed
his mind?"

You're *supposed* to have the secretary take all the calls, and then
pass along the calls to you that really need your attention.

If you stick apache in front of nginx, rather than the other way around,
what you're instead doing is having everyone call you, and then put the
secretary you hired on speakerphone while she takes the call...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] {OT} RAM & apache MaxClients (rock & a hard place)

[Michael Mol]

On 03/07/2013 03:45 PM, Grant wrote:
>>> I lowered my MaxClients setting in apache a long time ago after
>>> running out of memory a couple times.  I recently optimized my
>>> website's code and sped the site way up, and now I find myself
>>> periodically up against MaxClients.  Is a RAM upgrade the only
>>> practical way to solve this sort of problem?
>>
>> Use a reverse proxy in caching mode.
>>
>> A request served up by the proxy server is a request not served up by
>> Apache.
>>
>> Squid, nginx and varnish are all decent for the purpose, though squid
>> and nginx are probably the more polished than varnish.
> 
> Thanks Michael, I think I will set up nginx to serve my images.  That
> should take a big load off apache.  Is nginx still beneficial when
> using the Worker MPM?

It...depends?

nginx in reverse caching proxy mode will simply serve up objects before
the httpd it's protecting has to deal with them. Whether the type of an
MPM makes a significant difference on nginx's value depends more on what
kind of work you are (or aren't) asking Apache to do. I really couldn't
answer that for you without knowing the details behind what you're
running on top of Apache.

> 
> Should I be OK with NGINX_MODULES_HTTP="" in /etc/make.conf if I'm
> only serving images?

No idea. I've not used nginx, but it's highly recommended and widely
used for the purpose. You'll have to dig into the docs yourself. :-|





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] {OT} RAM & apache MaxClients (rock & a hard place)

[Michael Mol]

On 03/07/2013 10:49 AM, Florian Philipp wrote:
> Am 06.03.2013 22:30, schrieb Alan McKinnon:
>> On 06/03/2013 23:22, Michael Mol wrote:
>>> On 03/06/2013 04:07 PM, Alan McKinnon wrote:
>>>> On 06/03/2013 22:59, Michael Mol wrote:
>>>>> On 03/06/2013 03:54 PM, Grant wrote:
>>>>>> I lowered my MaxClients setting in apache a long time ago after
>>>>>> running out of memory a couple times.  I recently optimized my
>>>>>> website's code and sped the site way up, and now I find myself
>>>>>> periodically up against MaxClients.  Is a RAM upgrade the only
>>>>>> practical way to solve this sort of problem?
>>>>>
>>>>> Use a reverse proxy in caching mode.
>>>>>
>>>>> A request served up by the proxy server is a request not served up by
>>>>> Apache.
>>>>>
>>>>> Squid, nginx and varnish are all decent for the purpose, though squid
>>>>> and nginx are probably the more polished than varnish.
>>>>>
>>>>
>>>> Grant,
>>>>
>>>> If you optimized the site well, I would imagine your RAM needs per page
>>>> request would go down and you could possibly increase MaxClients again.
>>>> Have you given it a try since the optimization? Increase it slowly bit
>>>> by bit comparing the current performance with what it used to be, and
>>>> make your judgement call.
>>>>
>>>> Is there some reason why you can't just add more memory to the server?
>>>> It's a fast and very cheap and very effective performance booster with
>>>> very little downtime. But if your slots are full and you need new
>>>> hardware, that's a different story.
>>>>
>>>> Michael's proxy suggestion is excellent too - I use nginx for this a
>>>> lot. It's amazingly easy to set up, a complete breath of fresh air after
>>>> the gigantic do-all beast that is apache. Performance depends a lot on
>>>> what your sites actually do, if every page is dynamic with changing
>>>> content then a reverse proxy doesn't help much. Only you know what your
>>>> page content is like.
>>>
>>> The thing to remember is that clients request a *lot* of static content,
>>> too. CSS styles, small images, large images...these cache very well, and
>>> (IME) represent the bulk of the request numbers.
>>
>> 
>> Yes, of course. You are perfectly correct, I forget all about that
>> "invisible" stuff in the background
>> 
>>
>>
>>
>>>
>>> Unfortunately, with the way mod_php and friends work with Apache,
>>> resources consumed by static file requests aren't trivial once you
>>> realize that the big problem is with the number of concurrent
>>> requests...so it's best if those can be snapped up by something else, first.
>>>
>>> I've been running squid in front of my server for a few years. I've been
>>> eyeing CloudFlare, though; they're a CDN that behaves like a reverse
>>> proxy. You point their system at your server, your DNS at their system,
>>> and they'll do the heavy lifting for you. (And far better than having
>>> your own singular caching server would. I've worked at a CDN, and what
>>> they accomplish is pretty slick.)
>>>
>>>
>>>
>>
>>
> 
> To optimize the caching potential, there are a few tricks. There's an
> older tech talk about that from a Yahoo guy [1]. Google's advices are
> also worth reading [2] and for a quick and dirty solution, look at [3].
> 
> [1] https://www.youtube.com/watch?v=BTHvs3V8DBA
> [2] https://developers.google.com/speed/docs/best-practices/caching?hl=de
> [3] http://fennb.com/microcaching-speed-your-app-up-250x-with-no-n
> 
> BTW: What's the current status of MPM Worker or Event and PHP? Does it
> work? Does it help?

Never heard of MPM Event. MPM Worker combined with mod_php is unsupported.

Pretty much, I'm only aware of MPM Prefork or MPM ITK as working with
mod_php. If you go with fcgid, you can use just about anything on the
Apache side, from what I hear.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] {OT} RAM & apache MaxClients (rock & a hard place)

[Michael Mol]

On 03/06/2013 04:07 PM, Alan McKinnon wrote:
> On 06/03/2013 22:59, Michael Mol wrote:
>> On 03/06/2013 03:54 PM, Grant wrote:
>>> I lowered my MaxClients setting in apache a long time ago after
>>> running out of memory a couple times.  I recently optimized my
>>> website's code and sped the site way up, and now I find myself
>>> periodically up against MaxClients.  Is a RAM upgrade the only
>>> practical way to solve this sort of problem?
>>
>> Use a reverse proxy in caching mode.
>>
>> A request served up by the proxy server is a request not served up by
>> Apache.
>>
>> Squid, nginx and varnish are all decent for the purpose, though squid
>> and nginx are probably the more polished than varnish.
>>
> 
> Grant,
> 
> If you optimized the site well, I would imagine your RAM needs per page
> request would go down and you could possibly increase MaxClients again.
> Have you given it a try since the optimization? Increase it slowly bit
> by bit comparing the current performance with what it used to be, and
> make your judgement call.
> 
> Is there some reason why you can't just add more memory to the server?
> It's a fast and very cheap and very effective performance booster with
> very little downtime. But if your slots are full and you need new
> hardware, that's a different story.
> 
> Michael's proxy suggestion is excellent too - I use nginx for this a
> lot. It's amazingly easy to set up, a complete breath of fresh air after
> the gigantic do-all beast that is apache. Performance depends a lot on
> what your sites actually do, if every page is dynamic with changing
> content then a reverse proxy doesn't help much. Only you know what your
> page content is like.

The thing to remember is that clients request a *lot* of static content,
too. CSS styles, small images, large images...these cache very well, and
(IME) represent the bulk of the request numbers.

Unfortunately, with the way mod_php and friends work with Apache,
resources consumed by static file requests aren't trivial once you
realize that the big problem is with the number of concurrent
requests...so it's best if those can be snapped up by something else, first.

I've been running squid in front of my server for a few years. I've been
eyeing CloudFlare, though; they're a CDN that behaves like a reverse
proxy. You point their system at your server, your DNS at their system,
and they'll do the heavy lifting for you. (And far better than having
your own singular caching server would. I've worked at a CDN, and what
they accomplish is pretty slick.)





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] {OT} RAM & apache MaxClients (rock & a hard place)

[Michael Mol]

On 03/06/2013 03:54 PM, Grant wrote:
> I lowered my MaxClients setting in apache a long time ago after
> running out of memory a couple times.  I recently optimized my
> website's code and sped the site way up, and now I find myself
> periodically up against MaxClients.  Is a RAM upgrade the only
> practical way to solve this sort of problem?

Use a reverse proxy in caching mode.

A request served up by the proxy server is a request not served up by
Apache.

Squid, nginx and varnish are all decent for the purpose, though squid
and nginx are probably the more polished than varnish.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Programm for Floor Plans

[Michael Mol]

On 03/04/2013 10:23 PM, Francisco Ares wrote:
> 2013/3/4 Andrew Lowe <2505...@curtin.edu.au >
> 
> On 5/03/2013 8:52 AM, Andrey Moshbear wrote:
> 
> On Mon, Mar 4, 2013 at 6:56 PM, Silvio Siefke
> mailto:siefke_lis...@web.de>> wrote:
> 
> Hello,
> 
> 
> know someone a program for draw floor plans? I has use
> normal Visio for
> it, but unter Linux?
> 
> 
> Have you tried app-office/dia ?
> 
> 
> My two cents on dia: ugly, klunky, non intuitive, simple
> tasks are nearly, if not totally impossible to perform. I teach 1st
> year Engineering students and I recommend they look at Draftsight.
> It's not in portage, but is an easy install. It's also
> multiplatform, Linux, Win & Mac.
> 
> Regards,
> Andrew
> 
> 
> 
> I have tried to use Google Sketchup in the past, with little success,
> but I didn't persist as I should, I guess. Don't know if it is in
> portage, though.
> 
> If 2D drawing is enough, OpenOffice / LibreOffice have a vector drawing
> program, and Inkscape is just about it.
> 
> For a big shot, Blender is a 3D suite, but complex enough to scare a bit.

I saw FreeCAD demo'd at a local makerspace meeting. It looks like a good
place to go for people accustomed to AutoCAD. The guy demoing it uses it
to hand-digitize steam engine blueprints as a hobby. (And he's a Gentoo
user, albeit not on any of the lists or IRC channel, AFAIK)

For my 3D modelling needs, I've been using OpenSCAD...but that's very
much out of the way if you're looking to do floorplans.

DIA is a PITA if you're looking for Visio-like ease-of-use...but it's
the closest thing to Visio there is on Linux, AFAIK.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Changing static IP remotely...

[Michael Mol]

On 02/28/2013 05:43 PM, Florian Philipp wrote:
> Am 28.02.2013 16:37, schrieb Mike Gilbert:
>> On Thu, Feb 28, 2013 at 7:38 AM, Michael Mol  wrote:
>>> On 02/27/2013 11:48 PM, Jarry wrote:
>>>> Hi Gentoo users,
>>>>
>>>> what is the proper way of changing static IP-address remotely
>>>> without the need to restart the whole system (or locking
>>>> me out)?
>>>> [...]
>>>> # at -f /root/eth-restart now + 5 min
>>>> [...]
>>> Also, rather than using at to handle things like that, I like to use
>>> screen; if I get disconnected, programs running inside the screen
>>> session don't die...and there's no waiting for a scheduled job.
>>>
>>
>> Yeah, screen or tmux is the way to go.
>>
> 
> `nohup` would work too, right?

For what, exactly?




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Changing static IP remotely...

[Michael Mol]

On 02/27/2013 11:48 PM, Jarry wrote:
> Hi Gentoo users,
> 
> what is the proper way of changing static IP-address remotely
> without the need to restart the whole system (or locking
> me out)?
> 
> I have one interface with static IP, so first I'm going to edit
> /etc/conf.d/net. Then I will set up command for later execution:
> 
> # echo '#!/bin/bash' > /root/eth-restart
> # echo '/etc/init.d/net.eth0 restart' >> /root/eth-restart
> # chmod 0700 /root/eth-restart
> # at -f /root/eth-restart now + 5 min
> 
> Then I terminate my ssh-session hoping 5 minutes later
> I can connect using new IP. Is this correct and all that
> is necessary?
> 
> Jarry

Probably the safest thing you can do is give the interface two IPs at
once (both the old address and the new address) until you can confirm
you can connect on the new IP, and then remove the old IP.

Also, rather than using at to handle things like that, I like to use
screen; if I get disconnected, programs running inside the screen
session don't die...and there's no waiting for a scheduled job.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] [way OT] Authenticating in a wireless home network

[Michael Mol]

On 02/25/2013 01:56 AM, Mick wrote:
> On Monday 25 Feb 2013 03:00:56 Michael Mol wrote:

[snip]

> 
> Of course you could start covering the inside of your walls with aluminium 
> foil

My house has plaster-and-lathe walls and aluminum siding.

Frankly, it works out to about the same thing. >.<

[snip]




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] [way OT] Authenticating in a wireless home network

[Michael Mol]

On 02/24/2013 09:49 PM, walt wrote:
> I've been connecting my google nexus 7 tablet to my wireless router
> using the standard ssid/password method until last week, when I found
> that my router will allow wireless connections based on the tablet's
> MAC address.
> 
> What I don't know is whether the MAC-address authentication method
> will cause the wireless router to skip the password authentication
> entirely and accept the MAC address as 100% sole proof of identity.

Not unless there's something amazingly broken with it. And by that I
mean it would be newsworthy; the kind of thing Slashdot would jump on
before it sat in their queue five minutes.

MAC filtering, as it's called, is only trivially more secure than the
network would be without it. It adds just enough inconvenience that it's
unlikely for anyone to get on your network without directed attention or
prior planning for such circumstances.

> 
> I've heard that MAC address spoofing is easy given the right skills,
> so I don't know if relying solely on MAC address for authentication
> is asking for trouble, or not.
> 
> Your opinions are most welcome, the more paranoid the better :)
> 
> 

WPA-Enterprise is the most effective supported-by-default way to lock
down access to your wireless network...but it requires you to have a
RADIUS server on your network for your AP to check credentials against.
Every user of your network gets their own username and password, which
you configure on whatever authentication server the RADIUS server uses
as a back-end.

If that sounded confusing to you, it's probably far, far, far more than
you need.

Otherwise, WPA2-Personal is very good; it's a shared-key authentication
mechanism combined with better encryption and encryption application, as
well as key rotation. Chances are, it's what you're already using.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] traceroute not working

[Michael Mol]

On 02/22/2013 10:51 AM, Tanstaafl wrote:
> Hi all,
> 
> Weird, I don't use it much, but needed to run a traceroute today, and it
> is failing with:
> 
>  # traceroute 192.168.1.4
> traceroute to 192.168.1.4 (192.168.1.4), 30 hops max, 60 byte packets
> send: Operation not permitted
> 
> I know the problem is in my firewall, because when I stop it,
> traceroutes work as expected.
> 
> I have allowed all ICMP in my firewall:
> 
> Chain INPUT (policy DROP)
> target prot opt source   destination
> 
> ACCEPT icmp --  anywhere anywhere icmp any
> 
> 
> Chain FORWARD (policy DROP)
> target prot opt source   destination
> ACCEPT icmp --  anywhere anywhere icmp any
> 
> Chain OUTPUT (policy DROP)
> target prot opt source   destination
> 
> ACCEPT icmp --  anywhere anywhere icmp any
> 
> Any ideas what I'm missing?
> 
> I can send all of my firewall rules privately if someone thinks I may
> have something that is dropping these packets before my ALLOW rule kicks
> in, but I'm fairly sure I have them right...
> 
> Thanks
> 

Try moving your ACCEPT rules for icmp closer to (or all the way to) the top.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Calibre break after Update

[Michael Mol]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/17/2013 06:43 PM, ckard wrote:
> On Sun, Feb 17, 2013 at 11:24 PM, Silvio Siefke
>  wrote:
>> Hello,
>> 
>> 
>> i run the update from calibre yesterday and now calibre not
>> startet. Has someone the same and has fix?
>> 
>> siefke@gentoo-mobile : ~ $ calibre Traceback (most recent call
>> last): File "/usr/bin/calibre", line 20, in  
>> sys.exit(main()) File "/usr/lib/calibre/calibre/gui2/main.py",
>> line 412, in main app, opts, args, actions = init_qt(args) File
>> "/usr/lib/calibre/calibre/gui2/main.py", line 85, in init_qt from
>> calibre.gui2.ui import Main File
>> "/usr/lib/calibre/calibre/gui2/ui.py", line 31, in  from
>> calibre.gui2.widgets import ProgressIndicator File
>> "/usr/lib/calibre/calibre/gui2/widgets.py", line 21, in  
>> from calibre.gui2.progress_indicator import ProgressIndicator as
>> _ProgressIndicator File
>> "/usr/lib/calibre/calibre/gui2/progress_indicator/__init__.py",
>> line 15, in  pi_error) RuntimeError: Failed to load the
>> Progress Indicator plugin: the sip module implements API v9.0 to
>> v9.1 but the progress_indicator module requires API v8.1
>> 
>> Thank you & Greetings Silvio
>> 
> 
> You probably updated other python modules afterwards. Try to
> reinstall calibre.
> 

Wouldn't python-updater have caught that? I'm hitting the same error.
Tried python-updater, which gave me:

>>> Starting parallel fetch Emerging (1 of 12)
>>> dev-python/setuptools-0.6.30-r1 Installing (1 of 12)
>>> dev-python/setuptools-0.6.30-r1 Emerging (2 of 12)
>>> dev-python/pygments-1.5-r1 Installing (2 of 12)
>>> dev-python/pygments-1.5-r1 Emerging (3 of 12)
>>> dev-python/docutils-0.10 Installing (3 of 12)
>>> dev-python/docutils-0.10 Emerging (4 of 12)
>>> dev-python/markupsafe-0.15-r1 Emerging (5 of 12)
>>> dev-python/sip-4.14.3 Emerging (6 of 12)
>>> dev-java/java-config-2.1.12-r1 Installing (4 of 12)
>>> dev-python/markupsafe-0.15-r1 Installing (6 of 12)
>>> dev-java/java-config-2.1.12-r1 Installing (5 of 12)
>>> dev-python/sip-4.14.3 Emerging (7 of 12)
>>> net-misc/dropbox-1.2.48-r1 Emerging (8 of 12)
>>> dev-python/PyQt4-4.9.6-r2 Installing (7 of 12)
>>> net-misc/dropbox-1.2.48-r1 Emerging (9 of 12)
>>> dev-python/sphinx-1.1.3-r6 Installing (9 of 12)
>>> dev-python/sphinx-1.1.3-r6 Emerging (10 of 12)
>>> dev-python/beautifulsoup-4.1.3-r1 Installing (10 of 12)
>>> dev-python/beautifulsoup-4.1.3-r1 Emerging (11 of 12)
>>> dev-python/jinja-2.6-r1 Installing (11 of 12)
>>> dev-python/jinja-2.6-r1 Emerging (12 of 12)
>>> dev-python/lxml-3.0.1 Installing (12 of 12)
>>> dev-python/lxml-3.0.1 Installing (8 of 12)
>>> dev-python/PyQt4-4.9.6-r2 Jobs: 12 of 12 complete
>>> Load avg: 2.89,
2.27, 2.08

...but it didn't rebuild calibre. Anyway, trying rebuilding
app-text/calibre.

...and that worked for me.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRI+gMAAoJED5TcEBdxYwQx6cIAIaen4DoFtecHT4shkCEv6wb
mIGfWndewWMYGkEPKnROwJ2gJSUHWPh9kUq2HAyYxfSR0Jk+mcwXOUO8vHZJ7Occ
ZDMW/bLL8V/uEM/5jegqAM3+IzNf1R+EvOd9HImuUiFuy+7/h61MNyYCrhnOiSrW
HScNqvclEi9chP9tgwGOkMiBvPc/rHrQByiYA7auGJgox5OjyAuavpSEcC8/6JY8
NA3r1wB8D7yucsVroWkirkvsYR6OzCOz1XN4/0apxOWVg9PFusB/0XPCyydcIYl9
wwyu8JF/cPthO037EI3WzIflJENN+tKwSDVrQxJ/Oh9Q2geSz7dmjav/V2VaO9M=
=dmp/
-END PGP SIGNATURE-

Re: [gentoo-user] firehol + gentoo 3.6.11 kernel....

[Michael Mol]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/18/2013 11:12 PM, Pandu Poluan wrote:
> 
> On Feb 19, 2013 9:10 AM, "Michael Mol"  <mailto:mike...@gmail.com>> wrote:
>> 
>> On Feb 18, 2013 8:35 PM, "Tamer Higazi"  <mailto:th9...@googlemail.com>> wrote:
>>> 
>>> hi people! I have used all the time "firehol" (gentoo sources
>>> 3.3.8) to make my firewall rules. After kernel 3.4.x I can't
>>> make use of it any more.
>>> 
>>> Has anyone of you got firehol running on a genoo system with a
>>> 3.4.x kernel above to run? And if not, can you adivse me
>>> something similiar to build linux firewall rules ?!
>>> 
>>> For a short reply I would thank you.
>>> 
>>> 
>>> 
>>> Tamer
>>> 
>> 
>> I use a fork of firehol, based on Phil Whineray's IPv6
>> patches...but
> on Debian. I'll see about getting it working on Gentoo, and let
> you know. Perhaps I can get it (or Phil's version) into the tree.
> 
> Pah! Real Men™ hack iptables rules directly with their hands, not
> using baby walkers...
> 
> LOL, just kidding. What's the firehol fork's name in Debian? I'm 
> interested to see how it looks like now...
> 
> (About 4 years ago, these tools are so dismal I created one
> myself, failed miserably, and just code the rules up by hand.)
> 
> Rgds, --
> 

It's not in Debian, technically...

https://github.com/philwhineray/firehol-fork

Incidentally, firehol upstream isn't maintained any more. (Or wasn't
when Phil needed IPv6 support.) Also, firewall packages which don't
*explicitly* support IPv6 will not protect you from attackers using
IPv6; iptables and ip6tables are two separate commands. (One nice
thing about Phil's fork is that it defaults to applying policies to
both IPv4 and IPv6 where possible.)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRI6kOAAoJED5TcEBdxYwQdEkH/iwL6EqMDRpMxVqUgLwvTBzM
EE37/gA9xVItXFwgBi12Htva31FavRT5TCzoCNaMs/vU9s93+sx9YZRP2j1Z9dq5
bFrf2IBLGQzCmKu55ysxXp9D6ZAX9bULHteEvZDIgrkp8geCGjrBBwjuXX7bQ4RN
9TFwTIGfboUxYnJa4QTP7+diY/RET53oKBu69YCsHZbqDCJEa94mYuMdvoezob/G
L2HaX5VN5ABkmey2ZSc1nXmdTS7DxsTUI97VbxxWNl7B54gLzpMLl5h+iyYvHkhd
411fzyqz2WtjwwAa82cqQTfl7PMInpeZjLHHaKCFC9cVF+pagAdBtX3AfHUqXYI=
=Bph0
-END PGP SIGNATURE-

Re: [gentoo-user] firehol + gentoo 3.6.11 kernel....

[Michael Mol]

On Feb 18, 2013 8:35 PM, "Tamer Higazi"  wrote:
>
> hi people!
> I have used all the time "firehol" (gentoo sources 3.3.8) to make my
> firewall rules. After kernel 3.4.x I can't make use of it any more.
>
> Has anyone of you got firehol running on a genoo system with a 3.4.x
> kernel above to run?
> And if not, can you adivse me something similiar to build linux firewall
> rules ?!
>
> For a short reply I would thank you.
>
>
>
> Tamer
>

I use a fork of firehol, based on Phil Whineray's IPv6 patches...but on
Debian. I'll see about getting it working on Gentoo, and let you know.
Perhaps I can get it (or Phil's version) into the tree.

What error do you get?

Re: [gentoo-user] {OT} LWP::UserAgent slows website

[Michael Mol]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/11/2013 08:05 PM, Stroller wrote:
> 
> On 12 February 2013, at 00:04, Michael Mol wrote:
>>> I am sorry if I have caused you offence on any other occasion -
>>> if so, please feel free to explain why.
>> 
>> Primarily, what bothers me is your typically acerbic tone, and
>> that your posts often (at least to my perception) carry more
>> pejorative than useful information.
> 
> I have always attempted the very opposite.
> 
> I'm a little shocked, and will attempt to reassess with fresh eyes
> before posting in the future.
> 
> I can only hope you may have confused me with someone else.
> 
> I will occasionally make a terse response to a problem, asking no
> more than "have you checked X? what does /var/log/Y say? please
> post the output of `exec-Z`". In my experience, the right questions
> (i.e. the right choice of X, Y & Z) will most usually lead the
> poster to the solution.
> 
> Stroller.

I sincerely apologize. I will try to read your messages more clearly
in the tone they're obviously intended. Perhaps I do have you confused
with someone else. I hope so...either way, I apologize.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRGZiRAAoJED5TcEBdxYwQOfcIALZvCUe0G8yCNjkCZc57C6OW
ZwQLXErz+vPSo3U8FomwNrFFUVC5L726msPB6aKkuAZUSIA51Q0PLwLItxOJP2VJ
LwhmDyskbaqrYj1WIhmb7ASabGovpzo0GIOgvJuC2n/srAmb3qBeqlag9Zy/WwFt
miIwjXNqH1Nd0d6HlpX/O3f9kL1TBoohcUC4AwsQKWJfClohzkMalyls+OAWUs/r
5DD4nOv/53WjPLyVaKgeoNqPSaprAvuU2Em16y8ThUIrf2z/idxO+tUid4PfKscZ
s5GBxyDSqg+hzYyDQpfwx49ks7/NS9bvC/cIZKU0jeXhO+hXCOMl3Kzxu1ZDUEs=
=VPZ/
-END PGP SIGNATURE-

Re: [gentoo-user] {OT} LWP::UserAgent slows website

[Michael Mol]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/11/2013 06:07 PM, Stroller wrote:
> 
> On 11 February 2013, at 17:43, Michael Mol wrote:
>> ...
>>> If so, I don't understand why apache2 seems to bog down a bit
>>> for about 10 minutes afterward.
>> 
>> Now that's a new (and important!) piece of information. Your 
>> server runs slow for 10 *minutes* after your script has made its 
>> request?
> 
> This information is not new - it was in Grant's first post in this 
> thread, hence the reason I wondered if you'd read it.

*goes back in the thread*

Indeed it is, and I missed it. Whoops. I assembled my understanding of
the problem from subsequent posts, rather than the initial one.

> 
> I am sorry if I have caused you offence on any other occasion - if 
> so, please feel free to explain why.

Primarily, what bothers me is your typically acerbic tone, and that
your posts often (at least to my perception) carry more pejorative
than useful information. I greatly appreciate your more conciliatory
tone here!
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRGYckAAoJED5TcEBdxYwQ4u0IAKniOy6z8N890fi0YJPE96af
BOTI8jMZ/C2Qdgbg67vHb1yXR7LW+7RYk889PKLDkd3KYIG3KP2Zf1AN9bugjxEv
hiNHLLUSQhdjbuoDw1EVQCt8r1m7XbQdSRTAlVGWTf7H+MlPGR06JJRtQxCxOuIY
QChGpqeQEClR84D8Ml+bg3gkybYAratm2AY+mKv2GbVXydEu6guCN/1uje73F1dJ
fQO6/zQr285YrRYWGrRDM4xMosqEgubL0QDMJYHOaPtvvUE5M4wulelx41jYrD0D
wtGDxq0X01qDRRYWzs5tyDGgICYSp/YvxYs6SOCx6Asd4e0UwOW00RELkMB3bMA=
=40Yp
-END PGP SIGNATURE-

Re: [gentoo-user] {OT} LWP::UserAgent slows website

[Michael Mol]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/10/2013 08:53 PM, Stroller wrote:
> 
> On 10 February 2013, at 05:05, Grant wrote:
>>> ... Your server is just a single computer, running multiple
>>> processes. Each request from a user (be it you or someone else)
>>> requires a certain amount of resources while it's executing. If
>>> there aren't enough resources, some of the requests will have
>>> to wait until enough others have finished in order for the
>>> resources to be freed up.
>> 
>> Here's where I'm confused.  …   The responses are received and
>> displayed within about 3 seconds of when the requests are made.
>> … , I don't understand why apache2 seems to bog down a bit for
>> about 10 minutes afterward.
> 
> Seriously, after finishing Mr Mol's wall-of-text (learn to snip,
> Grant!) I wondered if he'd even read your question!
> 
> Stroller.
> 
> 

I've been using online communications for twenty years...and nobody
tempts me to create my first killfile like you do.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRGS4wAAoJED5TcEBdxYwQZEsIAI7eJacq8rIMP87EIVGvGrt+
z2xYvNohVovAI9b4sIwddL5spf4GLdVvvzjJNQqQb4e9wNgu08qPYCJCFNceSvE3
Hs/LNworkwFwFnNMK7jNfMaCp/GETFLMoaG/6A/jniKd1N/b/S5XBYfEqStbaaO8
vfqXCY6uem8p9zLig31eWDLzkIwanarp0LCUbZvDJbxaPpP6r9uRFVBBP/2IuvpS
u+XUEqYoeBBlzVo3wFqAUJMaSP5hLt6fEYXvId2VVcLwUfg653KwFgAXseYHDEci
vM39FeYUzwHevp7G7A1SYdKi0QmcIdfn2Pv96ZedSnjx/T0TglLJe3Y9DoY0x4c=
=TpVE
-END PGP SIGNATURE-

Re: [gentoo-user] {OT} LWP::UserAgent slows website

[Michael Mol]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/10/2013 12:05 AM, Grant wrote:
>>> The responses all come back successfully within a few seconds.
>>>  Can you give me a really general description of the sort of 
>>> problem that could behave like this?
>> 
>> Your server is just a single computer, running multiple
>> processes. Each request from a user (be it you or someone else)
>> requires a certain amount of resources while it's executing. If
>> there aren't enough resources, some of the requests will have to
>> wait until enough others have finished in order for the resources
>> to be freed up.
> 
> Here's where I'm confused.  The requests are made via a browser and
>  the response is displayed in the browser.  There is no additional
>  processing besides the display of the response.

You're running a client-side script that causes the *server* to do work.
The more work the server has to do, the slower it will perform for both
serving up your requests and those of other users. This is completely
independent of the work the client has to do.


> The responses are received and displayed within about 3 seconds of
>  when the requests are made.  Shouldn't this mean that all
> processing related to these transactions is completed within 3
> seconds?

There's client-side processing in handling the server's response, but
there's also server-side processing in handling the client's request.
What Stroller called a wall of text was a crash course in how a server
can have too many things to do in a short amount of time, and some of
the side-effects you can see--like having two nominally-3s queries both
appear to take 6s, from the client's perspective.

> If so, I don't understand why apache2 seems to bog down a bit for 
> about 10 minutes afterward.

Now that's a new (and important!) piece of information. Your server
runs slow for 10 *minutes* after your script has made its request?

To me, that indicates that important data wound up getting swapped to
disk on the server, and the slow behavior reported by other users is
the result of that data being swapped back in on-demand.

That also indicates that your script's requests (and, possibly,
request pattern) cause some process in the server to allocate far more
memory than usual, which is why the server is swapping things to disk.

Why, exactly, the server is consuming so much memory depends on a lot
of factors.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRGS3FAAoJED5TcEBdxYwQs7oH/3Xy0d85bNJ2QtQ4YcTF7g9E
TPZbwAUrwxrYf828AMlCUMOww2d1wr0DQOm4lBrzOb/93C8iwGKTjtu1dBaOspdC
mEdVmkFXF8YUB8yA3SiSgteHNCDrN27UyJQNP7mOK8PXwri4BYyxTUEJ0UyZXc4F
oIoSweHQg7tmyKN7Rudd69axREJ9yIpKt4lw7JZWHhX25hTVxWYF1zRDxNNC1vJ+
kQWSE3ZcP8EdotmcpARPF7N4leHOyU1+Rw9XatLVbb2W23Fza/4+Mqeam9fbObgH
w1mdMCzIUxlUL91nU7Zc0zzb2qYS7Te1N7bOcFr1fXowcCBagUdzOKjEcshket0=
=sWpw
-END PGP SIGNATURE-

Re: [gentoo-user] What to do with /var/run?

[Michael Mol]

On Sun, Feb 10, 2013 at 7:40 AM, Alan McKinnon  wrote:
> On 10/02/2013 13:49, Michael Mol wrote:
>> On Feb 10, 2013 3:29 AM, "Florian Philipp"  wrote:
>>>
>>> Am 10.02.2013 06:11, schrieb Grant:
>>>> I received the following ELOG message after an emerge:
>>>>
>>>>  * One or more symlinks to directories have been preserved in order to
>>>>  * ensure that files installed via these symlinks remain accessible.
>> This
>>>>  * indicates that the mentioned symlink(s) may be obsolete remnants of
>> an
>>>>  * old install, and it may be appropriate to replace a given symlink
>> with
>>>>  * the directory that it points to.
>>>>  *
>>>>  * /var/run
>>>>
>>>> Should I change anything?
>>>>
>>>> - Grant
>>>>
>>>
>>> If my understanding of the situation is correct, we see this message
>>> whenever a package is updated that in the old version installed to
>>> /var/run and now has migrated to /run.
>>>
>>> Even if I'm wrong, there is nothing to be done. /var/run is intended to
>>> be a symlink to /run. If it is, then all is fine.
>>>
>>> Regards,
>>> Florian Philipp
>>>
>>>
>>
>> Except we'll be seeing that elog to the end of time
>>
>> "lsof -n |grep /var/run" will tell you what, if anything running, is using
>> that symlink.
>>
>
> It's probably better to leave the symlink in place for now. What happens
> when the user installs a package they have never had before and that
> package uses /var/run?
>
> It will make a directory which isn't what you want.

Hm.

lsof -n|grep /var/run|cut -d\  -f1|sort -u

gives me

acpid
avahi-dae
bluetooth
cupsd
dbus-daem
gdm
syslog-ng

Of those, at least avahi and cups are emitting /var/run elogs, which
tells me they're defaulting to using /var/run instead of /run, if
/var/run is present.

Obviously, the transition isn't finished yet...software should default
to /run rather than /var/run, or the symlink can never be known to be
safe to remove on a given system.

> Better to leave the
> symlink in place and train your eyes to ignore the elogs (something we
> humans are extremely good at)

Oh god no...Then you end up like some folks who get bit every time
something changes (despite being warned about it for a months in
advance). :)


--
:wq

Re: [gentoo-user] What to do with /var/run?

[Michael Mol]

On Feb 10, 2013 3:29 AM, "Florian Philipp"  wrote:
>
> Am 10.02.2013 06:11, schrieb Grant:
> > I received the following ELOG message after an emerge:
> >
> >  * One or more symlinks to directories have been preserved in order to
> >  * ensure that files installed via these symlinks remain accessible.
This
> >  * indicates that the mentioned symlink(s) may be obsolete remnants of
an
> >  * old install, and it may be appropriate to replace a given symlink
with
> >  * the directory that it points to.
> >  *
> >  * /var/run
> >
> > Should I change anything?
> >
> > - Grant
> >
>
> If my understanding of the situation is correct, we see this message
> whenever a package is updated that in the old version installed to
> /var/run and now has migrated to /run.
>
> Even if I'm wrong, there is nothing to be done. /var/run is intended to
> be a symlink to /run. If it is, then all is fine.
>
> Regards,
> Florian Philipp
>
>

Except we'll be seeing that elog to the end of time

"lsof -n |grep /var/run" will tell you what, if anything running, is using
that symlink.