5 ms·

Not that this isn't a cool product, isn't it important to know your server can reboot?

by Already__Taken 13y ago

Gonzih 13y ago
Of course it can. It's just not necessary to reboot with solution like that.
- bananas 13y ago
  Until you reboot and it doesn't :)
  - ithkuil 13y ago
    And if you do reboot frequently but then at one point it doesn't work ? You either have a long downtime or have a secondary ready to take over. I understand you're talking about avoiding to rely on a false sense of confidence; that's a good rule of thumb, but shouldn't get in the way of better solutions: Test the secondary more often, and automate the recovery, and you'll cover more failure cases. You don't have the resources for a secondary ? This means you're to small; neither this tool is for you; keep it simple, and just reboot. Moreover, in some context is not desirable to perform a maintenance window until some designated moments like weekends. This means that you could leave your system vulnerable for up to a whole week.
    - jdsnape 13y ago
      I agree with what you're saying about having better recovery, but I think you need some balance between the two. I'd rather look through a week's worth of changes to work out what borked the restart than two years worth!
    - zyx321 13y ago
      >And if you do reboot frequently but then at one point it doesn't work ? Then you restore from yesterday's backup. It's probably still on-site. If a kernel live patch fails, you might not notice for a long time.
      - ithkuil 13y ago
        My point is you should always be prepared that a reboot doesn't work, since it could happen at any time between your maintenance windows. Frequently exercising a feature is a good idea, especially when you depend on that feature. That's why exercising backup restores is important; you want that to work when you need it. Do you really need a production machine to boot when you need it? I think is a wrong target to optimize for, given that that failure more is already covered by backups cold/hot secondary as long as you do exercise them frequently. That said, you do have a point about whether a live patch is reliable, but this doesn't have anything to do with whether increasing the average uptime of a host is a good or bad idea w.r.t to ensuring that the machine can start or not. TBH I wouldn't personally feel much comfortable using this live update thing, but I have no experience with it. I'd be curious to know more though.
sp332 13y ago
Sure, on a schedule. If a security patch comes out mid-day, it would be nice to be able to apply it without downtime.
- acdha 13y ago
  If downtime is a concern in any way, wouldn't you have at least two servers and thus the ability to do rolling reboots?
  - sp332 13y ago
    Sometimes downtime is in that grey area where you'd like to avoid it but it's not worth doubling your hardware costs. Or maybe your other server is already down for maintenance. Or you want both servers to be patched as soon as possible - simultaneously would be best.
  - timdorr 13y ago
    This is being marketed to shared web hosts with cPanel. This is a monolithic server architecture, so everything (web, mail, database, ftp, etc etc) runs on one server for each account. Hence, if you take the server down for a reboot, your customer is completely denied service until it comes back up.
mrweasel 13y ago
I really agree. You need to be able to reboot a server to patch it. If it's so important that your server do not reboot, it shouldn't be accessible by the general public. Assuming that you run some sort of website or internet service, you need to be able to deal with failing hardware/software anyway. Either you big enough to have redundant servers or you small enough that a reboot won't matter. I have a similar feelings towards backup and OS upgrades. You should be able to do a clean install and deploy your "stuff" on a blank server or vm somewhat quickly. If you 100% rely on say VMWare snapshots, you're doing something wrong.
- fragmede 12y ago
  If you're sufficiently big and have many, many servers, a full reboot cycle on all systems may take enough time that the ability to patch without having to reboot is even more valuable than for small companies.
- SoftwareMaven 12y ago
  In many cases, you do not need to be able to reboot a server to patch it. We patch the kernel regularly, allowing our customers to be protected without the hassle of rebooting. Applying patches to the kernel to fix security vulnerabilities is orthogonal to knowing you can reboot your server. Rebooting servers is more than "will it come back up", it also includes all the headache of scheduling and the risk of what happens if it doesn't come right back up. But, because servers can and do crash, hardware needs to be upgraded, etc., you certainly need to know you can bring your system back up from a cold state. Applying a hot fix means you are immediately protected from a vulnerability. Unless you are running at massive scale, few companies have an infrastructure that allows random servers to reboot (good on all those that do, regardless of scale!). Instead, most companies have systems and processes that make rebooting painful, especially for the IT guys who wind up working at 10pm on Saturday so they don't affect most people. And, until the reboot window opens up (whenever it is), your server is vulnerable. Disclaimer: I work on the Oracle Ksplice team.

Not that this isn't a cool product, isn't it important to know your server can reboot?

Gonzih 13y ago

Of course it can. It's just not necessary to reboot with solution like that.

bananas 13y ago
Until you reboot and it doesn't :)
- ithkuil 13y ago
  And if you do reboot frequently but then at one point it doesn't work ? You either have a long downtime or have a secondary ready to take over. I understand you're talking about avoiding to rely on a false sense of confidence; that's a good rule of thumb, but shouldn't get in the way of better solutions: Test the secondary more often, and automate the recovery, and you'll cover more failure cases. You don't have the resources for a secondary ? This means you're to small; neither this tool is for you; keep it simple, and just reboot. Moreover, in some context is not desirable to perform a maintenance window until some designated moments like weekends. This means that you could leave your system vulnerable for up to a whole week.
  - jdsnape 13y ago
    I agree with what you're saying about having better recovery, but I think you need some balance between the two. I'd rather look through a week's worth of changes to work out what borked the restart than two years worth!
  - zyx321 13y ago
    >And if you do reboot frequently but then at one point it doesn't work ? Then you restore from yesterday's backup. It's probably still on-site. If a kernel live patch fails, you might not notice for a long time.
    - ithkuil 13y ago
      My point is you should always be prepared that a reboot doesn't work, since it could happen at any time between your maintenance windows. Frequently exercising a feature is a good idea, especially when you depend on that feature. That's why exercising backup restores is important; you want that to work when you need it. Do you really need a production machine to boot when you need it? I think is a wrong target to optimize for, given that that failure more is already covered by backups cold/hot secondary as long as you do exercise them frequently. That said, you do have a point about whether a live patch is reliable, but this doesn't have anything to do with whether increasing the average uptime of a host is a good or bad idea w.r.t to ensuring that the machine can start or not. TBH I wouldn't personally feel much comfortable using this live update thing, but I have no experience with it. I'd be curious to know more though.

sp332 13y ago

Sure, on a schedule. If a security patch comes out mid-day, it would be nice to be able to apply it without downtime.

acdha 13y ago
If downtime is a concern in any way, wouldn't you have at least two servers and thus the ability to do rolling reboots?
- sp332 13y ago
  Sometimes downtime is in that grey area where you'd like to avoid it but it's not worth doubling your hardware costs. Or maybe your other server is already down for maintenance. Or you want both servers to be patched as soon as possible - simultaneously would be best.
- timdorr 13y ago
  This is being marketed to shared web hosts with cPanel. This is a monolithic server architecture, so everything (web, mail, database, ftp, etc etc) runs on one server for each account. Hence, if you take the server down for a reboot, your customer is completely denied service until it comes back up.

mrweasel 13y ago

I really agree. You need to be able to reboot a server to patch it. If it's so important that your server do not reboot, it shouldn't be accessible by the general public. Assuming that you run some sort of website or internet service, you need to be able to deal with failing hardware/software anyway. Either you big enough to have redundant servers or you small enough that a reboot won't matter. I have a similar feelings towards backup and OS upgrades. You should be able to do a clean install and deploy your "stuff" on a blank server or vm somewhat quickly. If you 100% rely on say VMWare snapshots, you're doing something wrong.

fragmede 12y ago
If you're sufficiently big and have many, many servers, a full reboot cycle on all systems may take enough time that the ability to patch without having to reboot is even more valuable than for small companies.
SoftwareMaven 12y ago
In many cases, you do not need to be able to reboot a server to patch it. We patch the kernel regularly, allowing our customers to be protected without the hassle of rebooting. Applying patches to the kernel to fix security vulnerabilities is orthogonal to knowing you can reboot your server. Rebooting servers is more than "will it come back up", it also includes all the headache of scheduling and the risk of what happens if it doesn't come right back up. But, because servers can and do crash, hardware needs to be upgraded, etc., you certainly need to know you can bring your system back up from a cold state. Applying a hot fix means you are immediately protected from a vulnerability. Unless you are running at massive scale, few companies have an infrastructure that allows random servers to reboot (good on all those that do, regardless of scale!). Instead, most companies have systems and processes that make rebooting painful, especially for the IT guys who wind up working at 10pm on Saturday so they don't affect most people. And, until the reboot window opens up (whenever it is), your server is vulnerable. Disclaimer: I work on the Oracle Ksplice team.