On Thu, 15 Sep 2011 19:46:30 -0700, Darren New wrote:

> On 9/15/2011 19:36, Jim Henderson wrote:
>> Yeah, kernel updates require a reboot.  Other than that, you usually
>> don't have to
> 
> Again, it depends on what you're doing and where the Linux is living.
> I'll grant that *desktop* linux systems rarely *need* rebooting. And I'd
> argue that if you have a server whose *only* job is being a web server,
> then restarting the web server after an upgrade is essentially the same
> as a reboot, except faster.

I don't see a need to regularly reboot Linux servers either, unless 
there's a kernel update.

Jim

Post a reply to this message

On Fri, 16 Sep 2011 09:34:42 +0100, Invisible wrote:

>> So then what's the problem?  You're complaining that they're not
>> tutorials, but they're not intended to be tutorials.
> 
> No, I'm complaining that tutorials don't exist. Only reference manuals.

Tutorials exist, they're not included with the OS.  Do I really need to 
say (again) "GIYF"?

>>> Since I'm guessing the answer is probably "yes", then I don't need to
>>> explain to you how hard it is...
>>
>> Yes, and I usually end up googling instead.  I'm sure I could figure it
>> out, but I don't need it that often.
> 
> Let's just hope you're not trying to look up how to configure Internet
> access...

I've managed to do that enough times that it generally isn't something I 
need to look up these days.  But if I did, a quick trip to my public 
library to use one of their computers to do the search will in fact solve 
that problem.

Or I could use my phone.

Or I could use another of my systems here.

>> It might be easier now, yes.  Honestly, I've never even looked for a
>> CHAP- based authentication mechanism for ssh.
> 
> No, I mean, I might be remembering this wrong.

That's certainly possible.

>>>> A sample size of 3 isn't exactly data supporting "commonly used".
>>>
>>> It's infinity times larger than a sample size of zero. ;-)
>>
>> Sure, but not mathematically significant.
> 
> Not /statistically/ significant, if you want to be picky.

Statistics is a branch of mathematics. :P

>>> Imagine it: Going to all the trouble of setting up a secure system,
>>> and not even knowing how to secure it properly...
>>
>> I don't have to - I see it fairly regularly.
> 
> This is the real WTF...

People who work in IT have not had to learn as much these days as they 
did 20 years ago.  That means they set up systems and often don't have 
the knowledge or skills to properly secure a system.

And the first thing to get cut from IT budgets is funding for training, 
usually.  Training that could actually resolve some of those security 
issues by having competent staff.

Jim

Post a reply to this message

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?  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? When you update the PRL on your 
android phone, what happens after the new PRL is stored?

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

Post a reply to this message

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

-- 
Regards
     Stephen

Post a reply to this message

Le 2011-09-15 22:10, Darren New a écrit :
> On 9/15/2011 18:19, Francois Labreque wrote:
>> Heathen! Linux machines do not need to be rebooted. Ever.
>
> I'm pretty sure you're wrong on that one.
>
A previous version of that post had a smiley at the end.  I guess it got 
lost during the vetting process.

-- 
/*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 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