171–180 of 201 posts
Earlier quoted context omitted.
Mainframes tend to be designed with extreme uptime in mind - to the point of often having hot-swappable processors .
The software doesn't care. It will crash anyway.
Earlier quoted context omitted.
I would advise exercising caution though. Even if the tool works perfectly fine, the service going down anywhere within days to weeks after you captured its state would be seen by the management as your fault. They won't care for the explanations, they will just need a scapegoat and that would be whoever touched the thing last time. That said, there are plenty of legitimate (albeit low-probability) reasons for the du…
I agree, there are actually two problems here: One is technical, and to do with the service and how to deal with it. One is political, and to do with who gets the blame when the service inevitably fails. OP needs to work out if they're being tasked with the job as the answer to the technical problem or the political problem. Because management could be very aware that this is a ticking bomb with no technical solution…
Earlier quoted context omitted.
I agree, there are actually two problems here: One is technical, and to do with the service and how to deal with it. One is political, and to do with who gets the blame when the service inevitably fails. OP needs to work out if they're being tasked with the job as the answer to the technical problem or the political problem. Because management could be very aware that this is a ticking bomb with no technical solution…
What good is a memory dump if you don't have the codebase to navigate? without the code and structure of how its managed a memory dump would just look like an alien language.
You need to know how machine instructions work, details of the operating system, and a bunch of other things... but any number of copy-protection systems have been bypassed this way. Any number of devices have had their firmware dumped, their memory scanned, and the resulting data analyzed to make patches or build compatible systems.
There was a active passive cluster with some complicated raid storage.
One day the passive's storage was gone(there were problems all along, corruptions, physical storage change/swap etc etc, mgmt put it on hold since there was a migration) and since there were already plans to migrate the cluster to somewhere else, no one from mgmt wanted to build another set of servers for such a "short" period.
Guess what... that short period was 18 months :)..
So for a 1 year and half , those systems were never touched and never restarted, all the time serving some applications out of it.
Sometimes we get lucky, sometimes we are out of job :)
Damn. Everyone here seems to advise you to just protect your own ass as a top priority. Is that a product of US work culture? If you where in a sound organisation, which I would say most Swedish IT organisations are, you need to think about the company and the clients first. Someone advised you to: “don’t do anything until explicitly asked to”. I think that’s just bad advise. You obviously know this is a major proble…
The main RPC service had a dependency on the lock service to start up and vice versa. If both services went globally offline at the same time, they wouldn't be able to turn either (thus most of Google) back on again.
Someone came up with a wonderful hack to solve this involving basically air-gaped laptops which when connected could help a datacenter bootstrap itself.
There is a tool used in malware analysis and computer forensics called Volatility[0]. It has some very powerful analysis tools and works on Linux Mac and Windows. In your case its ability to dump the memory of a running process without messing with the process state [1] may be very helpful! It also has the ability to run a Yara scan against the dumped memory which could let you find the region of memory containing th…
I would advise exercising caution though. Even if the tool works perfectly fine, the service going down anywhere within days to weeks after you captured its state would be seen by the management as your fault. They won't care for the explanations, they will just need a scapegoat and that would be whoever touched the thing last time. That said, there are plenty of legitimate (albeit low-probability) reasons for the du…
Reminds me of The Phoenix Project.
capture packet's and see what kind of traffic it receives most commonly The modern solution would be to capture the incoming packets as a training set then apply machine learning to create a model that can perfectly recreate the outgoing packets. It’s still an inexplicable black box of course, that is the nature of ML, but at least you can run it in the cloud now.