Re: [OpenIndiana-discuss] 3737 days of uptime
What about this one? http://arstechnica.com/information-technology/2013/03/epic-uptime-achievement-can-you-beat-16-years/ - Opprinnelig melding - Hi, all! I saw this on the Illumos developer list. I thought some of you might get a kick out of it. A Sun Solaris machine was shut down last week in Hungary, I think, after 3737 days of uptime. Below are links to the article and video. http://hardware.slashdot.org/story/13/03/14/2029205/solaris-machine-shut-down-after-3737-days-of-uptime http://www.youtube.com/watch?v=fAUvfqLEWuA Warning: It might bring a tear to your eye... [];-) Peter, hieromonk ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss -- Vennlige hilsener / Best regards roy -- Roy Sigurd Karlsbakk (+47) 98013356 r...@karlsbakk.net http://blogg.karlsbakk.net/ GPG Public key: http://karlsbakk.net/roysigurdkarlsbakk.pubkey.txt -- I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et elementært imperativ for alle pedagoger å unngå eksessiv anvendelse av idiomer med xenotyp etymologi. I de fleste tilfeller eksisterer adekvate og relevante synonymer på norsk. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] 3737 days of uptime
On 9 April 2013 15:06, Roy Sigurd Karlsbakk r...@karlsbakk.net wrote: What about this one? http://arstechnica.com/information-technology/2013/03/epic-uptime-achievement-can-you-beat-16-years/ we had a box that I installed in 1999 that was turned off when we moved out of the building in 2010 ... we found it hiding behind a fitted cupboard that had been installed after it :) It was a 386 running an early Linux, originally connected to a printer, via LPT, to make a network printer :) we hadn't had a printer plugged into it for about a year though :) so, no I can't beat it but I can guess at the servers irrelevance by that time :) ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] 3737 days of uptime
On 2013-04-09 16:26, Jonathan Adams wrote: we found it hiding behind a fitted cupboard that had been installed after it Well, there was a trend in 90's Russia to mount storage boxes into a wall, bricked forever, preferably with a wireless network. Whenever there were masked shows (tax police or competitors taking away all documentation required for work and stalling the raided company's activities for months on barely legal basis), some companies did have local backups with such means, as well as offsite backups (often too outdated for the really-needed documents submitted minutes before the raid). I am not sure uptimes were at premium, but ability for years of unserviced work in a couple of cubic feet of wallspace - yes, quite. See also: desire of patches that can make a system unbootable ;) //Jim ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] 3737 days of uptime
Edward Ned Harvey (openindiana) wrote: Patching is extremely safe. But let's look at the flip side. Suppose you encounter the rare situation where patching *does* cause a problem. It's been known to happen; heck, it's been known to happen *by* *me*. You have to ask yourself, which is the larger risk? Applying the patches, or not applying the patches? Extremely safe on anything OpenSolaris based! Hands up all those who've bricked a Linux system or had a Solaris 10 system that wouldn't play with live upgrade. -- Ian. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] 3737 days of uptime
On 4/8/2013 4:16 AM, Ian Collins wrote: Edward Ned Harvey (openindiana) wrote: Patching is extremely safe. But let's look at the flip side. Suppose you encounter the rare situation where patching *does* cause a problem. It's been known to happen; heck, it's been known to happen *by* *me*. You have to ask yourself, which is the larger risk? Applying the patches, or not applying the patches? Extremely safe on anything OpenSolaris based! Hands up all those who've bricked a Linux system or had a Solaris 10 system that wouldn't play with live upgrade. I have a Solaris 10 box who's LU is so completely fubar I can't do a thing with it. LU had some bugs there for a while. I think I found them all. :) -brian ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] 3737 days of uptime
On Mon, Apr 8, 2013 at 1:16 AM, Ian Collins i...@ianshome.com wrote: Hands up all those who've bricked a Linux system or had a Solaris 10 system that wouldn't play with live upgrade. I've had a couple instances where Linux systems wouldn't boot after kernel updates. Generally these have been software, not hardware issues -- some versions of the kernel changed how disks were identified. It's enough that I never apply kernel patches in a situation where it would be difficult to travel to the site (unless I have good IPMI console support.) I've had more issues where kernels caused performance or stability regressions. For a while regressions in NFSv4 stability were particularly common; Linux clients talking to OpenSolaris/OpenIndiana servers were, and continue to be, particularly problematic. It eventually became problematic enough that I scrapped NFSv4 and went to NFSv3, which also meant scrapping ZFS in situations where I couldn't use an automount map. I simply got tired of rebooting hung clients and servers, and having to explain to my users why the system was down yet again. -- David Brodbeck System Administrator, Linguistics University of Washington ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] 3737 days of uptime
On Mon, Apr 8, 2013 at 12:02 PM, David Brodbeck bro...@uw.edu wrote: On Mon, Apr 8, 2013 at 1:16 AM, Ian Collins i...@ianshome.com wrote: Hands up all those who've bricked a Linux system or had a Solaris 10 system that wouldn't play with live upgrade. I've had a couple instances where Linux systems wouldn't boot after kernel updates. Generally these have been software, not hardware issues -- some versions of the kernel changed how disks were identified. It's enough that I never apply kernel patches in a situation where it would be difficult to travel to the site (unless I have good IPMI console support.) Oh yeah -- another reason is I've run into many situations where OpenSolaris/OpenIndiana requires a full power cycle to reboot -- at least one of my machines hangs if I try to do a soft reboot in OI. -- David Brodbeck System Administrator, Linguistics University of Washington ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] 3737 days of uptime
On 2013-04-08 21:04, David Brodbeck wrote: Oh yeah -- another reason is I've run into many situations where OpenSolaris/OpenIndiana requires a full power cycle to reboot -- at least one of my machines hangs if I try to do a soft reboot in OI. Did you test if reboot -p (via PROM == via BIOS on x86) to disable fastboot helps in this case? While I don't remember hangs, there are kernel module complaints (something about PCI) when I do soft-reboots. If prom-reboot helps, you can reconfigure SMF to do it upon reboot. //Jim ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] 3737 days of uptime
Also, given the boot environments and live upgrade methods of OI and other Solaris derivatives, applying a patch is NOT dangerous. Apply, reboot into new environment (overnite??), and if things seem to have problems, go back to the old environment. The only caution that seems reasonable is to not apply too many patches or updates at once: in the outlandish case of a patch problem, you want to be able to guess with some accuracy which part of the patches applied had the problem. Doing the proper snapshots of non-BE datasets is of course required before rebooting into a test environment. On 2013-04-07 13:47, Edward Ned Harvey (openindiana) wrote: From: Ben Taylor [mailto:bentaylor.sol...@gmail.com] Patching is a bit of arcane art. Some environments don't have test/acceptance/pre-prod with similar hardware and configurations, so minimizing impact is understandable, which means patching only what is necessary. This thread has long since become pointless and fizzled, but just for the fun of it: I recently started a new job, where updates had not been applied to any of the production servers in several years. (By decree of former CIO). We recently ran into an obstacle where some huge critical deliverable was not possible without applying the updates. So we were forced, the whole IT team working overnight on the weekend, to apply several years' backlog of patches to all the critical servers worldwide. Guess how many patch-related issues were discovered. (Hint: none.) Patching is extremely safe. But let's look at the flip side. Suppose you encounter the rare situation where patching *does* cause a problem. It's been known to happen; heck, it's been known to happen *by* *me*. You have to ask yourself, which is the larger risk? Applying the patches, or not applying the patches? First thing to point out: Suppose you patch something and it goes wrong ... Generally speaking you can back out of the patch. Suppose you don't apply the patch, and you get a virus or hacked, or some data corruption. Generally speaking, that is not reversible. For the approx twice in my life that I've seen OS patches cause problems, and then had to reverse out the patches... I've seen dozens of times that somebody inadvertently sets a virus loose on the internal network, or a server's memory or storage became corrupted due to misbehaving processes or subsystem, or some server has some kind of instability and needs periodic rebooting, or becomes incompatible with the current release of some critical software or hardware, until you apply the patches. Patches are bug fixes and security fixes for known flaws in the software. You can't say if it ain't broke, don't fix it. It is broke, that's why they gave you the fix for it. At best, you can say, I've been ignoring it, and we haven't noticed any problems yet. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] 3737 days of uptime
Edward Ned Harvey (openindiana) wrote: From: Ben Taylor [mailto:bentaylor.sol...@gmail.com] Patching is a bit of arcane art. Some environments don't have test/acceptance/pre-prod with similar hardware and configurations, so minimizing impact is understandable, which means patching only what is necessary. This thread has long since become pointless and fizzled, but just for the fun of it: I recently started a new job, where updates had not been applied to any of the production servers in several years. (By decree of former CIO). We recently ran into an obstacle where some huge critical deliverable was not possible without applying the updates. So we were forced, the whole IT team working overnight on the weekend, to apply several years' backlog of patches to all the critical servers worldwide. Guess how many patch-related issues were discovered. (Hint: none.) Patching is extremely safe. But let's look at the flip side. Suppose you encounter the rare situation where patching *does* cause a problem. It's been known to happen; heck, it's been known to happen *by* *me*. You have to ask yourself, which is the larger risk? Applying the patches, or not applying the patches? First thing to point out: Suppose you patch something and it goes wrong ... Generally speaking you can back out of the patch. Suppose you don't apply the patch, and you get a virus or hacked, or some data corruption. Generally speaking, that is not reversible. For the approx twice in my life that I've seen OS patches cause problems, and then had to reverse out the patches... I've seen dozens of times that somebody inadvertently sets a virus loose on the internal network, or a server's memory or storage became corrupted due to misbehaving processes or subsystem, or some server has some kind of instability and needs periodic rebooting, or becomes incompatible with the current release of some critical software or hardware, until you apply the patches. Patches are bug fixes and security fixes for known flaws in the software. You can't say if it ain't broke, don't fix it. It is broke, that's why they gave you the fix for it. At best, you can say, I've been ignoring it, and we haven't noticed any problems yet. 10 years ago, it was the case that something like half the support calls would have never arisen if the system was patched up to date. (I don't know the current figure for this.) OTOH, I have worked in environments where everything is going to be locked down for 6-10 years. You get as current and stable as you can for the final testing, and then that's it - absolutely nothing is allowed to change. As someone else already hinted earlier in the thread, the security design of such infrastructure assumes from the outset that the systems are riddled with security holes, and they need to be made secure in some other (external) way. -- Andrew ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] 3737 days of uptime
Andrew Gabriel said the following, on 07-04-13 10:34 AM: Edward Ned Harvey (openindiana) wrote: From: Ben Taylor [mailto:bentaylor.sol...@gmail.com] Patching is a bit of arcane art. Some environments don't have test/acceptance/pre-prod with similar hardware and configurations, so minimizing impact is understandable, which means patching only what is necessary. This thread has long since become pointless and fizzled, but just for the fun of it: I recently started a new job, where updates had not been applied to any of the production servers in several years. (By decree of former CIO). We recently ran into an obstacle where some huge critical deliverable was not possible without applying the updates. So we were forced, the whole IT team working overnight on the weekend, to apply several years' backlog of patches to all the critical servers worldwide. Guess how many patch-related issues were discovered. (Hint: none.) Patching is extremely safe. But let's look at the flip side. Suppose you encounter the rare situation where patching *does* cause a problem. It's been known to happen; heck, it's been known to happen *by* *me*. You have to ask yourself, which is the larger risk? Applying the patches, or not applying the patches? First thing to point out: Suppose you patch something and it goes wrong ... Generally speaking you can back out of the patch. Suppose you don't apply the patch, and you get a virus or hacked, or some data corruption. Generally speaking, that is not reversible. For the approx twice in my life that I've seen OS patches cause problems, and then had to reverse out the patches... I've seen dozens of times that somebody inadvertently sets a virus loose on the internal network, or a server's memory or storage became corrupted due to misbehaving processes or subsystem, or some server has some kind of instability and needs periodic rebooting, or becomes incompatible with the current release of some critical software or hardware, until you apply the patches. Patches are bug fixes and security fixes for known flaws in the software. You can't say if it ain't broke, don't fix it. It is broke, that's why they gave you the fix for it. At best, you can say, I've been ignoring it, and we haven't noticed any problems yet. 10 years ago, it was the case that something like half the support calls would have never arisen if the system was patched up to date. (I don't know the current figure for this.) OTOH, I have worked in environments where everything is going to be locked down for 6-10 years. You get as current and stable as you can for the final testing, and then that's it - absolutely nothing is allowed to change. As someone else already hinted earlier in the thread, the security design of such infrastructure assumes from the outset that the systems are riddled with security holes, and they need to be made secure in some other (external) way And the side effect would be dramatically reduced OPEX due to lower numbers of stuff that should be supporting environment. --Roman ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] 3737 days of uptime
On 2013-04-07 16:34, Andrew Gabriel wrote: OTOH, I have worked in environments where everything is going to be locked down for 6-10 years. You get as current and stable as you can for the final testing, and then that's it - absolutely nothing is allowed to change. As someone else already hinted earlier in the thread, the security design of such infrastructure assumes from the outset that the systems are riddled with security holes, and they need to be made secure in some other (external) way. We've had projects where the axiom was A network-connected system is assumed compromised. It was even forbidden by law (maybe still is) to connect govt IT processing systems to public networks, so all kinds of the security gateway systems sprawled - in order to allow data exchange without having a networked connection, we made some too back in the day. Heck, for some deployments they discussed as appropriate to print out the input on one shore of the no-net gap and scan or type it in on the other. And this was even not some secret military, just govt-management stuff ;) //Jim Klimov ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] 3737 days of uptime
Patching is a bit of arcane art. Some environments don't have test/acceptance/pre-prod with similar hardware and configurations, so minimizing impact is understandable, which means patching only what is necessary. I prefer to patch everything when I build, or in environments where I have test/acceptance/pre-prod as it minimizes issues that I may not know exists. It also has the benefit of putting Oracle support in the seat of not being able to run their explorer analysis tool which always says your patches are out of date. My usual response is that's good, I got a tool like that too, and I didn't need you to tell me that. I had one experience with a new build, and a network problem, and engineer tells me my patches are out of date? I replied Oh, really, What does sed, awk, and Xvnc have to do with my network problem.? guy on the phone mumbles uhhh. uhhh.. uhhh. I told him I also had a patch tool to inform me what the status of my patches were, and I was pretty sure that none of those patches had anything to do with my network problem. Ticket was soon moved to someone who did more than just run an explorer through a tool. Ben On Fri, Apr 5, 2013 at 7:49 PM, David Brodbeck bro...@uw.edu wrote: On Wed, Mar 20, 2013 at 4:32 AM, Edward Ned Harvey (openindiana) openindi...@nedharvey.com wrote: It would only bring a tear to my eye, because of how foolishly irresponsible that is. 3737 days of uptime means 10 years of never applying security patches and bugfixes. Whenever people are proud of a really long uptime, it's a sign of a bad sysadmin. Depends on the environment it's running in. It might be a closed, air-gapped network, for example -- those still exist, especially in industrial settings. In those cases taking the risk of patching a system that's not at risk and has been running well would be the irresponsible thing to do. Frankly, on a server that old, powering it down will probably destroy it -- a hard disk that's been spinning that long is unlikely to spin up again once stopped. I tend not to blindly patch my production machines, especially during the academic term when it might be disruptive to students and to running research jobs. I generally go through the update list and pick and choose stuff that is a risk to my installation -- for example, on a file server, I might patch Samba but ignore X, because it has no local users and will never be running an X server. Kernel updates for security problems in drivers for devices I don't own are another area I ignore. Generally there has to be a security hole in the kernel that can be used to escalate privileges before I'll do a reboot mid-term. This is especially true of the Linux kernel, where new kernel versions often bring unexpected regressions. -- David Brodbeck System Administrator, Linguistics University of Washington ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] 3737 days of uptime
On Wed, Mar 20, 2013 at 4:32 AM, Edward Ned Harvey (openindiana) openindi...@nedharvey.com wrote: It would only bring a tear to my eye, because of how foolishly irresponsible that is. 3737 days of uptime means 10 years of never applying security patches and bugfixes. Whenever people are proud of a really long uptime, it's a sign of a bad sysadmin. Depends on the environment it's running in. It might be a closed, air-gapped network, for example -- those still exist, especially in industrial settings. In those cases taking the risk of patching a system that's not at risk and has been running well would be the irresponsible thing to do. Frankly, on a server that old, powering it down will probably destroy it -- a hard disk that's been spinning that long is unlikely to spin up again once stopped. I tend not to blindly patch my production machines, especially during the academic term when it might be disruptive to students and to running research jobs. I generally go through the update list and pick and choose stuff that is a risk to my installation -- for example, on a file server, I might patch Samba but ignore X, because it has no local users and will never be running an X server. Kernel updates for security problems in drivers for devices I don't own are another area I ignore. Generally there has to be a security hole in the kernel that can be used to escalate privileges before I'll do a reboot mid-term. This is especially true of the Linux kernel, where new kernel versions often bring unexpected regressions. -- David Brodbeck System Administrator, Linguistics University of Washington ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] 3737 days of uptime
I was watching this discussion thread with interest so I checked system uptimes. My AMD64 Solaris 10 system was just about to reach exactly one year of uptime. When it reached one year of uptime, then BOOM, system panic for unknown (to me) reason. I recall that the same thing happened to my SPARC Solaris 10 system. System panic after one year of uptime seems like too much of a coincidence to me ... No 3737 days of uptime to report here. :-( Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] 3737 days of uptime
Edward Ned Harvey (openindiana) said the following, on 20-03-13 7:32 AM: From: dormitionsk...@hotmail.com [mailto:dormitionsk...@hotmail.com] Sent: Tuesday, March 19, 2013 11:42 PM A Sun Solaris machine was shut down last week in Hungary, I think, after 3737 days of uptime. Below are links to the article and video. Warning: It might bring a tear to your eye... It would only bring a tear to my eye, because of how foolishly irresponsible that is. 3737 days of uptime means 10 years of never applying security patches and bugfixes. Whenever people are proud of a really long uptime, it's a sign of a bad sysadmin. Not to mention the bill for electricity. --Roman ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] 3737 days of uptime
From: dormitionsk...@hotmail.com [mailto:dormitionsk...@hotmail.com] Sent: Tuesday, March 19, 2013 11:42 PM A Sun Solaris machine was shut down last week in Hungary, I think, after 3737 days of uptime. Below are links to the article and video. Warning: It might bring a tear to your eye... It would only bring a tear to my eye, because of how foolishly irresponsible that is. 3737 days of uptime means 10 years of never applying security patches and bugfixes. Whenever people are proud of a really long uptime, it's a sign of a bad sysadmin. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] 3737 days of uptime
On 03/20/2013 12:32 PM, Edward Ned Harvey (openindiana) wrote: It would only bring a tear to my eye, because of how foolishly irresponsible that is. 3737 days of uptime means 10 years of never applying security patches and bugfixes. Whenever people are proud of a really long uptime, it's a sign of a bad sysadmin. 1) Reboot is only required when applying kernel patches or big clusters which affect core services (and the admin is using BEs). 2) Not all machines are web-facing and thus don't necessarily need regular security patching. 3) If it ain't broken, don't fix it. Not everybody can afford the luxury of periodic maintenance downtime and certain systems are required to be 100% available, though I will admit that these are few and far between (and in most cases a good hot-spare policy will take care of this). -- Saso ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] 3737 days of uptime
long uptimes are not hard to achieve. i bet if i got my old sparc ipx out from college days and booted it the system would report about thirteen years if uptime. i think i last used it in the summer of 2000. i shut it down last time by putting it to sleep. when it boots, assuming battery is good shape, it should have all that elapsed time as uptime. but you right, i didnt apply any patches. something tells me its as secure as the day i packed it away :) j. Sent from Jasons' hand held On Mar 20, 2013, at 4:55 AM, Sašo Kiselkov skiselkov...@gmail.com wrote: On 03/20/2013 12:32 PM, Edward Ned Harvey (openindiana) wrote: It would only bring a tear to my eye, because of how foolishly irresponsible that is. 3737 days of uptime means 10 years of never applying security patches and bugfixes. Whenever people are proud of a really long uptime, it's a sign of a bad sysadmin. 1) Reboot is only required when applying kernel patches or big clusters which affect core services (and the admin is using BEs). 2) Not all machines are web-facing and thus don't necessarily need regular security patching. 3) If it ain't broken, don't fix it. Not everybody can afford the luxury of periodic maintenance downtime and certain systems are required to be 100% available, though I will admit that these are few and far between (and in most cases a good hot-spare policy will take care of this). -- Saso ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] 3737 days of uptime
I had to reboot after about 200 days of uptime the other day because I updated netatalk, which created a new BE. I don't really understand why a non-kernel package, for a non-essential service, would need a new BE. Is there a way to avoid this kind of thing so in the future I can brag about uptime? On Wed, Mar 20, 2013 at 3:06 PM, Jason Matthews ja...@broken.net wrote: long uptimes are not hard to achieve. i bet if i got my old sparc ipx out from college days and booted it the system would report about thirteen years if uptime. i think i last used it in the summer of 2000. i shut it down last time by putting it to sleep. when it boots, assuming battery is good shape, it should have all that elapsed time as uptime. but you right, i didnt apply any patches. something tells me its as secure as the day i packed it away :) j. Sent from Jasons' hand held On Mar 20, 2013, at 4:55 AM, Sašo Kiselkov skiselkov...@gmail.com wrote: On 03/20/2013 12:32 PM, Edward Ned Harvey (openindiana) wrote: It would only bring a tear to my eye, because of how foolishly irresponsible that is. 3737 days of uptime means 10 years of never applying security patches and bugfixes. Whenever people are proud of a really long uptime, it's a sign of a bad sysadmin. 1) Reboot is only required when applying kernel patches or big clusters which affect core services (and the admin is using BEs). 2) Not all machines are web-facing and thus don't necessarily need regular security patching. 3) If it ain't broken, don't fix it. Not everybody can afford the luxury of periodic maintenance downtime and certain systems are required to be 100% available, though I will admit that these are few and far between (and in most cases a good hot-spare policy will take care of this). -- Saso ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss -- Seconds to the drop, but it seems like hours. http://www.openmedia.ca https://robbiecrash.me ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] 3737 days of uptime
I worked for QNX back in the early 2000's. At that time QNX had a fairly complete design for performing kernel upgrades on a live system. Because QNX is a microkernel, this was doable. I can't get too deep into the details, but essentially it required a set of permanently reserved memory pages for the incoming kernel .text, as well as a runtime requirement that sufficient free RAM existed to hold a copy of the current kernel data structures at the time of the upgrade. The ability to upgrade the layout of kernel data structures was addressed. Because (in QNX) all drivers are implemented as user processes there was no need to interfere with them during the upgrade process (it was completely transparent to interrupt handlers - i.e. zero latency impact for interrupt handlers). There was a temporal disruption to the scheduling of threads waiting on interrupts at the moment of the upgrade and to threads being scheduled as a result of kernel timers, but it was small and predictable based on the size of the allocation of kernel data structures at the time of the upgrade. I believe that by the late 2010's any truly industrial strength O/S will require the ability to handle live kernel upgrades. On a microkernel O/S it is highly likely that the kernel will never need to be upgraded to remediate a security issue (the QNX kernel itself is EAL4 certified, and only needs to insure that message passes are encrypted and only accessible to correctly credentialed threads in order to remain that way over the long haul). The only plausible requirement to upgrade the kernel for security reasons would be if the message crypto algorithm had been permanently cracked. Privilege escalation issues, etc., would all have to occur via vulnerabilities in user space processes (which can be easily dynamically patched). Basically, my point here, is that it is erroneous to assume that servers should have to be reset in order for security to be maintained over the long haul. On 3/20/13 12:06 PM, Jason Matthews ja...@broken.net wrote: long uptimes are not hard to achieve. i bet if i got my old sparc ipx out from college days and booted it the system would report about thirteen years if uptime. i think i last used it in the summer of 2000. i shut it down last time by putting it to sleep. when it boots, assuming battery is good shape, it should have all that elapsed time as uptime. but you right, i didnt apply any patches. something tells me its as secure as the day i packed it away :) j. Sent from Jasons' hand held On Mar 20, 2013, at 4:55 AM, Sašo Kiselkov skiselkov...@gmail.com wrote: On 03/20/2013 12:32 PM, Edward Ned Harvey (openindiana) wrote: It would only bring a tear to my eye, because of how foolishly irresponsible that is. 3737 days of uptime means 10 years of never applying security patches and bugfixes. Whenever people are proud of a really long uptime, it's a sign of a bad sysadmin. 1) Reboot is only required when applying kernel patches or big clusters which affect core services (and the admin is using BEs). 2) Not all machines are web-facing and thus don't necessarily need regular security patching. 3) If it ain't broken, don't fix it. Not everybody can afford the luxury of periodic maintenance downtime and certain systems are required to be 100% available, though I will admit that these are few and far between (and in most cases a good hot-spare policy will take care of this). -- Saso ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] 3737 days of uptime
I'm waiting for 7337 days before mine go down ;) On 20 March 2013 14:41, dormitionsk...@hotmail.com dormitionsk...@hotmail.com wrote: Hi, all! I saw this on the Illumos developer list. I thought some of you might get a kick out of it. A Sun Solaris machine was shut down last week in Hungary, I think, after 3737 days of uptime. Below are links to the article and video. http://hardware.slashdot.org/story/13/03/14/2029205/solaris-machine-shut-down-after-3737-days-of-uptime http://www.youtube.com/watch?v=fAUvfqLEWuA Warning: It might bring a tear to your eye... [];-) Peter, hieromonk ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss -- Kind regards, Jules golgy whats so wrong with plumb? hoolio nothing, in itself. it's just for me, knowing what it means infers i cannot any longer pretend to not be a complete square when it comes to computers Gryphon I don't know that knowing anything about plumb turns you into a nerd, but this conversation already has hoolio are you calling me nerdy? checkers hoolio: you know what initramfs means, AND does. You're lost to the non-geek world already Gryphon yes hoolio hrm hoolio goodbye cruel world. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
