|
Just don't forget to run it every now and then, there sadly is a reason they made such a stupid move. 
|
|
|
|
|
|
This is why I am really thinking, Linux is a better way to go than Windows OS, for server apps.
At this point, what with the .NET Core, Mono C#, etc., I shouldn't have any problems running a C# web server on Linux. I'll have to give that a try actually.
[edit]And as for the database, I really like PostgreSQL, and I think there's Linq2SQL support for that (I don't use EF!), though not sure. And since I'm not tied in with IIS on any of my web apps, I don't have to worry about that! [/edit]
Marc
|
|
|
|
|
I've always been a *Nix fan since I was a teenager, it's just this app requires Windows or else I wouldn't bother with it.
Jeremy Falcon
|
|
|
|
|
I know 'Topshelf' and I'm pretty sure 'Quartz.Net' also runs on Mono, so Linux is a serious option for services in C# 
|
|
|
|
|
Npgsql[^]
PostgreSQL data provider for .NET.
It's awesome.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
Jeremy Falcon wrote: Windows will up and just restart la la la without a care to the wind for a *server* app?
Hi,
An unpatched server on a network increases the risk of attack on all of the other networked devices.
It's time for everyone to realize that many computing devices are part of a global interconnected network. Over the last decade we have relied on human server administrators to be responsible for keeping up-to-date and applying security patches. That is not working very well.
It seems perfectly reasonable to give the server administrator several days or perhaps weeks to perform a manual reboot. if that does not happen... force the update.
I would suggest having a look at Manage updates using Windows Update for Business[^]
Most feature updates may be deferred for up to 180 days. Some security updates can be deferred for up to 30 days depending on severity. Unfortunately there are also remotely exploitable security issues that simply cannot be deferred.
One last thing...
You heard it here first. Within the next decade Linux distro organizations will be highly encouraged to have a similar forced-update mechanism. This will probably be negotiated and network-enforced via future trade agreements such as TPP and NAFTA and/or other future agreements.
Best Wishes,
-David Delaune
|
|
|
|
|
Dude. I don't think you realize I'm a very senior level professional that's fullly aware of all of this. Also, if you really think deferrring will stop it from rebooting when it feels like it, maybe you should take a look again. When it does decide to eventually install the update it will reboot whether you like it or not. And without consent.
And Unix and most likely Linux will never adopt this. Everyone knows a magical reboot you have no real control over is foolish. Everybody. Except MS it seems.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: Also, if you really think deferrring will stop it from rebooting when it feels like it, maybe you should take a look again. When it does decide to eventually install the update it will reboot whether you like it or not. And without consent.
I thought that's exactly what Randor said:
Randor wrote: It seems perfectly reasonable to give the server administrator several days or perhaps weeks to perform a manual reboot. if that does not happen... force the update
Jeremy Falcon wrote: And Unix and most likely Linux will never adopt this
One could argue that the exact opposite of this might happen (both opinions being predictions anyway), but only time will tell what would happen.
|
|
|
|
|
Rajesh R Subramanian wrote: I thought that's exactly what Randor said:
Not quite. Delaying something doesn't mean it'll magically stop from a reboot without your knowledge when it finally does decided to download a patch. It just simply defers the "magical reboot". Your server can still go down willy nilly, just 180 days later than everyone else.
Rajesh R Subramanian wrote: One could argue that the exact opposite of this might happen (both opinions being predictions anyway), but only time will tell what would happen.
One could, but then they'd be wrong. 
Jeremy Falcon
|
|
|
|
|
CoreOs already does that, they have it as one of the reasons to choose them[^].
|
|
|
|
|
Keep in mind I'm new to containers but even with that I could see it... almost. Not so much in a server environment though. And I'm sure some people will use a container on a server but I digress.
Jeremy Falcon
|
|
|
|
|
Randor wrote: It seems perfectly reasonable to give the server administrator several days or perhaps weeks to perform a manual reboot. if that does not happen... force the update.
Absolutely NOT. Computer systems are tools of the business, not the other way around.
The vendor does not own the environment, does not manage the environment, and has absolutely no say in how the environment is managed. They can recommend, but it is NOT their call.
I have worked in complex, highly regulated environments where any computer rebooting in the middle of a process will cause (at least) hundreds of thousands of dollars in damage, not including loss of business due to loss of confidence by the customers. People get fired for doing anything that negatively affects such processes, so I don't expect any OS that can force reboots will be allowed.
|
|
|
|
|
BryanFazekas wrote: Absolutely NOT. Computer systems are tools of the business, not the other way around.
It's always easy to see when someone is speaking from experience or not. You sir, sound like you're speaking from experience.
BryanFazekas wrote: The vendor does not own the environment, does not manage the environment, and has absolutely no say in how the environment is managed. They can recommend, but it is NOT their call.
BryanFazekas wrote: I have worked in complex, highly regulated environments where any computer rebooting in the middle of a process will cause (at least) hundreds of thousands of dollars in damage
I knew it. I could tell this before I got to this part. I think anyone with any real server admin experience would agree with you and I.
Jeremy Falcon
|
|
|
|
|
And how much do you pay out from those hundreds of thousand dollars to those clients who lost everything using your service because a timing issue existed in your system unpatched? Or because Google is your competitor[^]?
|
|
|
|
|
Peter Adam wrote: And how much do you pay out from those hundreds of thousand dollars to those clients who lost everything using your service because a timing issue existed in your system unpatched?
This has nothing to do with the point of allowing a known defect (unmanaged server reboot) into a business process.
|
|
|
|
|
Jeremy Falcon wrote: There's no way to stop this thing from magically rebooting
I think that I can say with pretty much absolute certainty that the adjective I would have used is not "magically".
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Touché.
Jeremy Falcon
|
|
|
|
|
I don't get how you want to 'keep going 24/7' and have this running on a single server and not in a cluster (in VM's on a Nano Server or something...)
|
|
|
|
|
Fair enough, but still doesn't mean a magical reboot is a good idea.
Jeremy Falcon
|
|
|
|
|
So Netflix reboot there servers all the time, and they have no idea when it's going to happen. It makes their system more robust.
I know they are an extreme example, but I think it shows that if you can't handle a machine reboot, it means that your architecture is wrong for 24/7 up time.
If you are designing applications for a cloud environment then following the 12 factor approach is a good start, specifically The Twelve-Factor App - Disposability[^]
|
|
|
|
|
While I agree, that in the context of something redundant, "underlying OS for a cloud", etc. that's just a node on a cluster of machines, a single machine reboot can be acceptable. I don't agree that forcing it upon the user within a guest VM or legit server is prudent. And since Windows update tends to release updates for all at the same time, it would force more than one machine to reboot at similar times. I don't agree with that, it takes the assumptions that server admins are smart enough to figure out how to keep machines up to date.
Jeremy Falcon
|
|
|
|
|
After giving this much thought, I'm going to side with Microsoft on this one. A server is intended to be part of a domain and to therefore adopt the domain policies once deployed. Until then, it should default to the most fanatically secure/paranoid state possible. Public facing system deployment should be done with deliberation requiring opt-out options for anything related to security.
|
|
|
|
|
You disagreeing with me... again? Say it isn't so. 
I don't agree with MS. I've administered ISPs. Under no circumstance should a machine go down without the admin having a say-so in it. This takes the assumption a sys admin is a retard who can't patch his/her system without being spoon fed.
Jeremy Falcon
|
|
|
|
|
This is about a default configuration, not a deployed configuration. A server should never be deployed in its default configuration. The unfortunate reality is that many admins aren't doing due diligence in setting up servers. The number of unpatched servers of all OS varieties is astonishing.
Another point is that Microsoft intends Windows Server to be used on a domain with domain policies in place, not stand-alone.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
