On Fri, 16 Sep 2011 10:01:51 -0700, Darren New wrote:

> On 9/16/2011 9:54, Jim Henderson wrote:
>> I don't see a need to regularly reboot Linux servers either, unless
>> there's a kernel update.
> 
> So when the memory leak in your Linux-based wireless access point
> crashes your machine, what do you do?  

I report the bug with supporting data, build the latest version of the 
code, and try to fix it.  I don't just reboot it.

In fact, I went through something very similar to this not long ago - my 
wireless router/access point runs openWRT, and a recent update borked the 
atheros driver.  Rebuilt the older kernel, reported the bug, and applied 
the downgrade.

> When your cable box no longer
> synchronizes with the cable provider, or you get a new configuration
> pushed to your cable modem from the head end, what do you do? 

Well, I don't have cable any more (it was an expense we had to cut when I 
was laid off).  But that's an appliance, not the same as "running a Linux 
server" in my book.  If Comcast wants to reboot their box, they can 
reboot their box.

> When you
> update the PRL on your android phone, what happens after the new PRL is
> stored?

Again, not a Linux *server* - it's an appliance.  If Verizon decides the 
phone needs rebooted, then it gets rebooted.

There's probably a way to do this without rebooting the device 
(especially if it's rooted), but often times it's just simpler to reboot.

That doesn't mean a reboot is *necessary*, which is what we were 
discussing.

Jim

Post a reply to this message

On Fri, 16 Sep 2011 18:06:01 +0100, Stephen wrote:

> On 16/09/2011 5:57 PM, Jim Henderson wrote:
>> Training that could actually resolve some of those security issues by
>> having competent staff.
> 
> You're asking a lot there, Jim. ;-)

Indeed, I am - but things could get interesting here job-wise, as I've 
found a job where I might actually have to solve that one. :)

Jim

Post a reply to this message

On Fri, 16 Sep 2011 13:16:49 -0400, Jim Henderson wrote:

> On Fri, 16 Sep 2011 18:06:01 +0100, Stephen wrote:
> 
>> On 16/09/2011 5:57 PM, Jim Henderson wrote:
>>> Training that could actually resolve some of those security issues by
>>> having competent staff.
>> 
>> You're asking a lot there, Jim. ;-)
> 
> Indeed, I am - but things could get interesting here job-wise, as I've
> found a job where I might actually have to solve that one. :)

(Not as in "been given an offer for", rather I found a posting that I'm 
applying for)

Jim

Post a reply to this message

Le 2011-09-16 04:30, Invisible a écrit :
>
> With NAT, it can work perfectly well. At long as each endpoint knows the
> other only by its publicly routable IP address, anyway.

Correction: as long as both endpoints know each other by an address that 
works for them.

I know of customers who do inbound natting of third party servers as 
well, because they don't want to route the public IP range inside their 
network.

> There are probably web servers that run on RFC-1918 IP addresses.

I would wager that the vast majority of them do.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

Le 2011-09-16 04:28, Invisible a écrit :
>>> Sometimes I think it would be nice if there was a widely-supported
>>> standard for configuring the firewall at the /other end/ of the last
>>> mile to drop certain packets. But anyway...
>>
>> A DDoS needs to be extremely big for an ISP to notice one of its
>> customers is under attack. And you need a special business relationship
>> to be able to call them up and ask that they block a certain type of
>> traffic at the head end.
>
> Quite. I did actually hear about a guy having to spend ages on the phone
> to their ISP to ask for firewall configuration changes.
>
> Now imagine if there were a standard, widely-implemented system for
> letting the customer make those configuration changes themselves...
> Let's face it, the ISP's routers are almost certainly remote-manageable
> anyway. If the unwanted packets can be blocked at the entrance to the
> ISP's network, they can save themselves the bother of having to route a
> bunch of traffic. (Although the amount of data you can fire at one
> customer is probably peanuts compared to the ISP network capacity.)
>
> Ah well, dream on...

Then it would take 2.5 nanoseconds for a hacker to steal your 
credentials and make those changes for you.  BLAM! total denial of service.

Some IDS/IPS vendors have programmed routines in their systems that can 
automatically change firewall rules in the event that they detect an 
attack, yet the majority of installations leave this feature turned off 
because people are afraid of false alerts blocking valid traffic, and 
having HAL in control of the pod bay doors.

I'm sure ISPs feel the same way about having their customers be able to 
play with their firewall configs.
-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

On 16/09/2011 6:17 PM, Jim Henderson wrote:
>>
>>> On 16/09/2011 5:57 PM, Jim Henderson wrote:
>>>> Training that could actually resolve some of those security issues by
>>>> having competent staff.
>>>
>>> You're asking a lot there, Jim. ;-)
>>
>> Indeed, I am - but things could get interesting here job-wise, as I've
>> found a job where I might actually have to solve that one. :)
>
> (Not as in "been given an offer for", rather I found a posting that I'm
> applying for)
>

Good luck with that one. I hope that you can deliver on time and in 
budget ;-)


-- 
Regards
     Stephen

Post a reply to this message

On 9/16/2011 10:15, Jim Henderson wrote:
>  not the same as "running a Linux server" in my book.

I agree. That's precisely my point.  Saying "you never have to reboot a 
Linux machine except for kernel upgrades" is incorrect. It assumes the box 
has all the tools it needs to manage it without rebooting, and it assumes 
your software environment isn't hardened against you manipulating it in the 
ways described.

> That doesn't mean a reboot is *necessary*, which is what we were
> discussing.

OK, so how do you upgrade your PRL without rebooting your phone? My point is 
that claiming "you don't have to" assumes a whole bunch of facts that 
aren't true just because you're running Linux.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On Fri, 16 Sep 2011 12:00:28 -0700, Darren New wrote:

> On 9/16/2011 10:15, Jim Henderson wrote:
>>  not the same as "running a Linux server" in my book.
> 
> I agree. That's precisely my point.  Saying "you never have to reboot a
> Linux machine except for kernel upgrades" is incorrect. It assumes the
> box has all the tools it needs to manage it without rebooting, and it
> assumes your software environment isn't hardened against you
> manipulating it in the ways described.

You specified servers and desktops - not appliance devices.

I also never said "you never have to reboot a Linux machine except for 
kernel updates".  I said "you usually never have to reboot a Linux 
machine except for kernel updates".  There's a world of difference in 
those two statements.

I also very specifically stated that if you're dealing with zombie 
processes, a Linux system *requires* a reboot to the best of my knowledge.

>> That doesn't mean a reboot is *necessary*, which is what we were
>> discussing.
> 
> OK, so how do you upgrade your PRL without rebooting your phone? My
> point is that claiming "you don't have to" assumes a whole bunch of
> facts that aren't true just because you're running Linux.

I've never had a need to, so I don't know.  Presumably you could stop a 
service or unload/reload a driver, or drop to single user mode and then 
go back to the default runlevel.

Jim

Post a reply to this message

On Fri, 16 Sep 2011 19:10:30 +0100, Stephen wrote:

> On 16/09/2011 6:17 PM, Jim Henderson wrote:
>>>
>>>> On 16/09/2011 5:57 PM, Jim Henderson wrote:
>>>>> Training that could actually resolve some of those security issues
>>>>> by having competent staff.
>>>>
>>>> You're asking a lot there, Jim. ;-)
>>>
>>> Indeed, I am - but things could get interesting here job-wise, as I've
>>> found a job where I might actually have to solve that one. :)
>>
>> (Not as in "been given an offer for", rather I found a posting that I'm
>> applying for)
>>
>>
> Good luck with that one. I hope that you can deliver on time and in
> budget ;-)

A little late on the "on time" bit (I had wanted to be back to work about 
2 months ago - but only in a position that was right for me), but yeah, I 
think this could work out well once I get the resume into the right 
person's hands.  The trick is making sure it gets to the right person 
rather than going through "the front door".

Jim

Post a reply to this message

On 9/16/2011 12:57, Jim Henderson wrote:
> You specified servers and desktops - not appliance devices.

No I didn't.  I was responding to someone else's comment of

 >> Heathen! Linux machines do not need to be rebooted. Ever.

That didn't say "Linux machines with a full development environment 
installed and to which you have root access never have to be rebooted." 
That's my point here. :-)

> I've never had a need to, so I don't know.  Presumably you could stop a
> service or unload/reload a driver, or drop to single user mode and then
> go back to the default runlevel.

Cool. How do I drop to single-user mode on my cell phone?

Again, you're making assumptions that the linux in your phone (or your cable 
box or your credit card terminal) is like the linux in your desktop or 
server machine.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message