I know. Longest uptime is silly, macho, pointless stuff... but I ran across
an old SunOS 2.6 box that had been up for 387 days. It had been hacked. The
only reason it was not an open mail relay is that /var was full. So, I
thought to myself, "I bet I could run an OpenBSD box for that amount of time
or longer without getting hacked and without doing much to it." Just
wondering what's the longest OpenBSD uptime some folks on misc have seen?

Thanks
-- 
View this message in context: http://www.nabble.com/Longest-Uptime--tp20219082p20219082.html
Sent from the openbsd user - misc mailing list archive at Nabble.com.

[ message continues ]

What is your point? Dogs live way longer than that. Just put one in 
front of your hosting provider and you should be safe for about 15 
years.

Nice things about dogs is that they don't need rebooting.

-- 
Antoine

[ message continues ]

When I built a NAT gateway for home some five years ago (On OpenBSD  
3.4), it could go on for more than 580 days without rebooting (though  
it didn't act as a public mail server), after which point I had a  
power outage and decided anyway to apply updates more diligently  
given the hassle it is to upgrade / reinstall a box all the way to  
the latest version when you let more than one version pass. :)
-- 
Stephane LAPIE
Email: lapie@aozora-is.co.jp
Phone: +81 (0)42 319 5164

[ message continues ]

Hmm, yeah sure I'll bite. The longest I've seen that I still have a
record of (screen shot of the uptime command) was a machine I
installed as a firewall for a very important mail server. Please note,
I was not in charge of maintaining it, otherwise it would not have
reached this uptime, but it was over two years. As far as I could tell
(I got onto the box once in a blue moon) it was not hacked, but seeing
as all it did was run pf, and only allowed ssh from 2 IP addresses
(both I controlled, and were firewalled themselves), that doesn't seem
extraordinary. I will type out the uptime/uname command as in the
picture:

$ uptime
10:54AM  up 745 days, 22:36, 0 users, load averages: 0.13, 0.09, 0.08
$ uname -a
OpenBSD bassfishing 3.1 GENERIC#0 i386
$

As far as uptimes I don't have records of, a friend of mine has worked
on old systems that weren't rebooted because they were afraid it would
not boot back up again. One of them pre-internet, I believe it did
some financial stuff. However, no proof there.

-- 
Jason

[ message continues ]

I think Art's the final word, but one of the more impressive uptimes I
heard about was this vax system in .de or some such.  They kept the
uptime even across 2 cross-town moves!  This was quite a few moons
ago.


-- 
http://www.glumbert.com/media/shift
http://www.youtube.com/watch?v=tGvHNNOLnCk
"This officer's men seem to follow him merely out of idle curiosity."
-- Sandhurst officer cadet evaluation.
"Securing an environment of Windows platforms from abuse - external or
internal - is akin to trying to install sprinklers in a fireworks
factory where smoking on the job is permitted."  -- Gene Spafford
learn french:  http://www.youtube.com/watch?v=j1G-3laJJP0&feature=related

[ message continues ]

Hi all

I have a simple 2 disk RAID 1 array which has become corrupted by a 
faulty memory module.

If I repeatedly generate an MD5 hash on the same file, I consistantly 
get 1 of 2 values back, roughly alternating, so I assume that the 2 
disks have different versions of the same file and they are accessed 
more-or-less alternately. 'raidclt -s' tells me that all is well with 
the array.
It appears that the likelyhood of corruption is greater with larger 
files - >approx 1/2 gig are pretty much all corrupt while small files 
are pretty much all ok. All this sounds reasonable under the 
circumstances.

My idea on recovering as much as possible was to disconnect 1 drive, 
copy all the data off, switch to the other drive and do the same, then 
run an anaysis on the 2 copies - if a file is the same on both copys, 
the it's probably ok, if they differ, then one or both will be bad.

So, I did the first copy, but when I swap to the other disk, RAIDFrame 
has remembered that this has 'failed' so will not configure it into the 
set (as I feared it would(nt)).

Does anyone know how I can tell RAIDFrame that the first drive is 
actually ok, or is my reasoning just nonsense anyway?
What would a parity re-write do in this case?

Ironicaly this computer is in the process of being configured as backup 
storage, so while I have the originals of most of the data, there is 
some that I dont, and I haven't yet set up the secondary (off site) 
backups. And yes I did test the backups were ok, the first ones at 
least. It appears the module failed some time during the process. I 
know, I should have been anal and checked every single one, but it was 
all brand new hardware ...
Actually, that's when failure rates are high.


paulm

[ message continues ]

I think the final word on this was pronounced
(perhaps predictably) by Artur Grabowski.

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

See especially the link in the foregoing message:

http://www.blahonga.org/~art/diffs/epenis-enlargement.20060210

-wb

[ message continues ]

We all have embarrassing secrets regarding systems we've failed to 
properly maintain, but bragging about uptime is just like bragging 
about the ugliest people you've slept with.

Sure, you did it, but that doesn't make it a good idea.

(Jon glances lustfully at his ancient but seldom used laptop)

--
Jon

[ message continues ]

... From a file I sent the output of uptime and date to a while back...

 bash-2.04$ cat 1111.days
 2:08PM  up 1111 days, 19:28, 2 users, load averages: 0.11, 0.12, 0.08
 Fri Mar 23 14:08:50 PDT 2007

Soon after that the UPS my box was connected to at the ISP died and had
to be replaced.

It's still a stock 2.8 GENERIC#399 i386 system that has seen many
attacks but not a break in. It's not a critical system, only my toy box.
While the big uptime was fun I now believe in doing my updates/upgrades
and rebooting a little more often.

C

-----Original Message-----
From: owner-misc@openbsd.org [mailto:owner-misc@openbsd.org] On Behalf
Of J.C. Roberts
Sent: Tuesday, October 28, 2008 7:30 PM
To: new_guy
Cc: misc@openbsd.org
Subject: Re: Longest Uptime?


We all have embarrassing secrets regarding systems we've failed to
properly maintain, but bragging about uptime is just like bragging about
the ugliest people you've slept with.

Sure, you did it, but that doesn't make it a good idea.

(Jon glances lustfully at his ancient but seldom used laptop)

--
Jon

[ message continues ]

Hmm,

what about 180-190 days uptime max?
Afaik you need to reboot your OpenBSD when you upgrade in May and
November...

guido

[ message continues ]

On Tue, Oct 28, 2008 at 11:45 PM, Guido Tschakert

Just hope an important kernel update doesn't come by within those six
months.  ;)

[ message continues ]

7:52AM  up 6134 days, 16:36, 3 users, load averages: 0.52, 0.47, 0.43

http://www.blahonga.org/~art/diffs/epenis-enlargement.20060210

//art

[ message continues ]

It is not the size of your uptime that matters, it is what you do with it.

Gilles

[ message continues ]

Hi,

Uptimes sucks. Here's the biggest i've ever seen in the company i work:

[operator@optg998 ~]$ uname -a
SunOS optg998 5.6 Generic_105181-26 sun4u sparc SUNW,UltraSPARC-IIi-cEngine
[operator@optg998 ~]$ uptime
  3:40pm  up 2639 day(s), 13:50,  1 user,  load average: 0.08, 0.07, 0.06
[operator@optg998 ~]$ date
Wed Oct 29 15:45:24 BRST 2008
[operator@optg998 ~]$ psrinfo -v
Status of processor 0 as of: 10/29/08 15:41:07
  Processor has been on-line since 08/08/01 00:50:54.
  The sparc processor operates at 440 MHz,
        and has a sparc floating point processor.
[operator@optg998 ~]$ dmesg | tail -5
SUNW,hme0: Using External Transceiver
SUNW,hme0: 100 Mbps half-duplex Link Up
dump on /dev/md/dsk/d50 size 2042608K
SUNW,hme0: Using External Transceiver
SUNW,hme0: full-duplex Link Up

Ok it's not OpenBSD, blame on me. But what i liked is that this
machine is working for 2639 days and it stills blink green leds. The
harddisk never gave up too. No errors on dmesg.
It's a Netra T1 machine, running our internal DNS server. I think
we'll replace it when it dies ;)


[ message continues ]

On Wed, Oct 29, 2008 at 1:49 PM, guilherme m. schroeder

We bought 2 machines (together).  Expensive ones.  After putting them
in, my peon walks around looking at them.  One had a green blinking
power led.  All is well.  The other had a red blinking power led.
Peon went nuts looking in the documentation, etc etc.  Diagnostics and
everything seems to indicate the system is working.  Called support
up.  After a while, they finally figured out what was the problem.
The vendor neglected to spec the color of the power led, and had
sourced it from 2 different factories.  So, one factory put in a green
led, and the other put in a red one.

I have since made it my life's mission to tell every single one of
their reps that in a data center, you only want to see green blinking
lights, not red blinking lights.


-- 
http://www.glumbert.com/media/shift
http://www.youtube.com/watch?v=tGvHNNOLnCk
"This officer's men seem to follow him merely out of idle curiosity."
-- Sandhurst officer cadet evaluation.
"Securing an environment of Windows platforms from abuse - external or
internal - is akin to trying to install sprinklers in a fireworks
factory where smoking on the job is permitted."  -- Gene Spafford
learn french:  http://www.youtube.com/watch?v=j1G-3laJJP0&feature=related

[ message continues ]

Okai,

here's my $0.02 on the subject:

http://systemnet.no/ios-uptime.jpg


/Pete








[ message continues ]

Now *that* is nuts!

Not upgrading IOS every other day that is...


[ message continues ]

What about having the greatest downtime ?

Means running windows ?

Nope, sorry, just not having the computer plugged ...

Ain't that great ? ;)

[ message continues ]

http://www.crice.org

[ message continues ]

Well, I can see a pattern...

Every year or so, someone runs into a Linux box that has not been 
rebooted or patched in a LONG time, usually because someone else higher 
in company's hierarchy doesn't want it rebooted.
Then, amazed by the fact that an idle box does not crash when left doing 
nothing but idle, he just HAS to come over and brag about the uptime of 
that mostly idle box because it is three or more digits long.

The truth is, most people here don't care about uptime, let alone the 
uptime of Linux boxes, and in OpenBSD land you better have a GOOD reason 
to have an uptime longer than two releases.
Obviously, being amazed by the uptime of an idle box is not really a 
good reason ;-)

Gilles,
proud to never exceed 200 days of uptime

[ message continues ]

Speaking of which... I think I have a pretty good reason to bring
down my uptime very shortly. YAY!

~% uptime
10:39AM  up 82 days, 14:06, 1 user, load averages: 0.22, 0.20, 0.17



# Han

[ message continues ]

SunOS 2.6 was released in 1999.  if someone can really run a 9-yr-old
release of *anything* exposed to the internet without "doing much to it,"
and still avoid compromise, that would be a pretty good trick.

...lori

[ message continues ]

Yes, I agree. But I have seen systems that old online in the year 2008. The
latest one was running on 15 year old Sun hardware. SunOS 2.6. It had been
hacked. I found it because it was infected with stacheldracht... remember
that? One of the first DDOS tools. And it was phoning home to a handler
(they did not refer to them as 'controllers' back in 1999). You'd be
surprised... especially in higher-ed IT environments. Research professors
with Nobel Peace prizes in science have dusty, old research labs full of
systems like this... and yes, they are online :)

-- 
View this message in context: http://www.nabble.com/Longest-Uptime--tp20219082p20306106.html
Sent from the openbsd user - misc mailing list archive at Nabble.com.

[ message continues ]