6 ms·

Here’s another perspective: A decade ago you could deploy an internal PHP app to a box and forget about it for a few years, then fix a minor bug by sshing in,

by shocks 3y ago

Here’s another perspective: A decade ago you could deploy an internal PHP app to a box and forget about it for a few years, then fix a minor bug by sshing in, viming a file, and hacking it a few times. These days, if you leave the app untouched for six months that 10 minute fix becomes 2 hours of fixing a broken docker build. :)

ilyt 3y ago
As an admin of PHP apps at that time I can sincerely say screw you, you're lying. PHP apps breaking because new version of PHP shat on compatibility was pretty common, and weirdly enough got more common in newer versions. You also had to keep unholy combo of php extensions (why that garbage is in app server and not app) and server config because the special little retard that designed the app decided he must do something different. And forget about ever leaving apache, if it doesn't use some apache module to fix PHP/developer ineptitude it will at least have half of the request routing logic in .htaccess file.
- shocks 3y ago
  > forget about it for a few years No version upgrade required. :D
  - andrelaszlo 3y ago
    Haha yeah I can say, with the same sincerity, that I get occasional calls about fixing PHP apps that I built 2007-2013. They've been running (without upgrades) on some forgotten server in a multinational corporation. I tell them that they should let their compliance department know, that the version of PHP isn't even supported, and I list some of the thousand security fixes that they aren't using. I usually end up VPN/FTP:ing into a forgotten era to add the fixes and I definitely don't want to go back.
    - progmetaldev 3y ago
      I had this happen about a year and a half ago with an application I wrote in 2009. Finally got them to allow me to rewrite everything in C#, allowing me to keep up to date on security vulnerabilities and performance improvements, without having to do much but run through a series of tests when a NuGet package or .NET version upgrade is released. NuGet with current .NET is a far different beast now, than when you used .NET Framework and plenty of XML assembly binding.
  - mm007emko 3y ago
    At the time we were reluctant to update even our linux servers. We had only critical security fix repos enabled and checked them once a week. No, we didn't update PHP unless strictly needed.
  - ilyt 3y ago
    If you piss on security sure but then every language is "easy" if you just need to deploy once and forget about the server for forever
edejong 3y ago
In the meantime, your PHP app had 40 major security flaws, no meaningful monitoring, a DB that wasn't backed up and major data consistency problems. Also, when your box's hdd crashed, you lost all those minor changes you had vim'ed over the years. But for the rest, yeah, all is fine.
- shocks 3y ago
  If you forget about a PHP container for a few years it will /also/ have 40 new vulnerabilities. Actually, containers are worse because OS updates of core shared libraries do nothing. You have to rebuild every damn container. Setting up monitoring for your docker containers is also a whole thing. :) I think you’re taking my example a little too literally. My point is not that docker/k8s/whatever is bad; just that the ‘new’ adds features at the cost of simplicity.
  - makeitdouble 3y ago
    The biggest thing with containers is, these 40 vulnerabilities won't matter as much if they're about erasing your directories or killing your machine. It will get rebooted in a pristine state and an attacker would need to stick there killing it at every reboot to have lasting effect. Which is also the point of monitoring a container, which is fairly reliable nowadays, compared to managing your own health check service to ping your box to check if it's alive. All in all, I think k8s is way too complicated for what it does for most people, but administrating servers was also a complex task to begin with, and the things sys admins were dealing with looked nightmarish to me. Heck, there was a time companies would have their own SMTP in house...
    - dumpsterdiver 3y ago
      > won't matter as much if they're about erasing your directories or killing your machine Those sort of attacks have tapered off though, right? Unless you're engaged in a specific feud, or have caught the ire of a social justice warrior, these days we're mostly looking at data exfiltration as the primary goal. That being said, there are a lot of ongoing feuds and active social justice warriors.
ubertaco 3y ago
>then fix a minor bug by sshing in, viming a file, and hacking it a few times. Yeah, screw version control! Who needs any record of the change you made? If you have to move the code or redeploy it somewhere because that server goes down or something else changes, _real_ 10x rockstar ninjas remember every change they've made for the last several years.
- zdragnar 3y ago
  Not to mention the paper trail needed for any meaningfully regulated industry. The thought of someone just ssh'ing into an application with access to PII or HIPAA regulated data and being able to tweak the production code is nightmare fuel.

by shocks 3y ago

ilyt 3y ago

As an admin of PHP apps at that time I can sincerely say screw you, you're lying. PHP apps breaking because new version of PHP shat on compatibility was pretty common, and weirdly enough got more common in newer versions. You also had to keep unholy combo of php extensions (why that garbage is in app server and not app) and server config because the special little retard that designed the app decided he must do something different. And forget about ever leaving apache, if it doesn't use some apache module to fix PHP/developer ineptitude it will at least have half of the request routing logic in .htaccess file.

shocks 3y ago
> forget about it for a few years No version upgrade required. :D
- andrelaszlo 3y ago
  Haha yeah I can say, with the same sincerity, that I get occasional calls about fixing PHP apps that I built 2007-2013. They've been running (without upgrades) on some forgotten server in a multinational corporation. I tell them that they should let their compliance department know, that the version of PHP isn't even supported, and I list some of the thousand security fixes that they aren't using. I usually end up VPN/FTP:ing into a forgotten era to add the fixes and I definitely don't want to go back.
  - progmetaldev 3y ago
    I had this happen about a year and a half ago with an application I wrote in 2009. Finally got them to allow me to rewrite everything in C#, allowing me to keep up to date on security vulnerabilities and performance improvements, without having to do much but run through a series of tests when a NuGet package or .NET version upgrade is released. NuGet with current .NET is a far different beast now, than when you used .NET Framework and plenty of XML assembly binding.
- mm007emko 3y ago
  At the time we were reluctant to update even our linux servers. We had only critical security fix repos enabled and checked them once a week. No, we didn't update PHP unless strictly needed.
- ilyt 3y ago
  If you piss on security sure but then every language is "easy" if you just need to deploy once and forget about the server for forever

edejong 3y ago

In the meantime, your PHP app had 40 major security flaws, no meaningful monitoring, a DB that wasn't backed up and major data consistency problems. Also, when your box's hdd crashed, you lost all those minor changes you had vim'ed over the years. But for the rest, yeah, all is fine.

shocks 3y ago
If you forget about a PHP container for a few years it will /also/ have 40 new vulnerabilities. Actually, containers are worse because OS updates of core shared libraries do nothing. You have to rebuild every damn container. Setting up monitoring for your docker containers is also a whole thing. :) I think you’re taking my example a little too literally. My point is not that docker/k8s/whatever is bad; just that the ‘new’ adds features at the cost of simplicity.
- makeitdouble 3y ago
  The biggest thing with containers is, these 40 vulnerabilities won't matter as much if they're about erasing your directories or killing your machine. It will get rebooted in a pristine state and an attacker would need to stick there killing it at every reboot to have lasting effect. Which is also the point of monitoring a container, which is fairly reliable nowadays, compared to managing your own health check service to ping your box to check if it's alive. All in all, I think k8s is way too complicated for what it does for most people, but administrating servers was also a complex task to begin with, and the things sys admins were dealing with looked nightmarish to me. Heck, there was a time companies would have their own SMTP in house...
  - dumpsterdiver 3y ago
    > won't matter as much if they're about erasing your directories or killing your machine Those sort of attacks have tapered off though, right? Unless you're engaged in a specific feud, or have caught the ire of a social justice warrior, these days we're mostly looking at data exfiltration as the primary goal. That being said, there are a lot of ongoing feuds and active social justice warriors.

ubertaco 3y ago

>then fix a minor bug by sshing in, viming a file, and hacking it a few times. Yeah, screw version control! Who needs any record of the change you made? If you have to move the code or redeploy it somewhere because that server goes down or something else changes, _real_ 10x rockstar ninjas remember every change they've made for the last several years.

zdragnar 3y ago
Not to mention the paper trail needed for any meaningfully regulated industry. The thought of someone just ssh'ing into an application with access to PII or HIPAA regulated data and being able to tweak the production code is nightmare fuel.