4 ms·
But the problem is the inverse one: given a library, which project in your org depends on it? Possibly a project tucked away into a repository that a developer
by Xylakant 5y ago
But the problem is the inverse one: given a library, which project in your org depends on it? Possibly a project tucked away into a repository that a developer maintained that just left last week and that just happens to be deployed on an external facing web server.
It’s easier for Java based apps since you can just scan the machines they’re deployed on, but it’s hard for C and the like.
- samus 5y agoYeah, there was also a deployable that ops almost forgot about, but I remembered. But even in C, you can inspect the symbol table of binaries. Unless they got stripped or optimized away, of course. Edit: yes, deployables that nobody knows about and just sit there for years are a huge problem.
- mst 5y agoProvided the dependency is dynamically linked, you can find everything running against an old version of the .so after it's been updated by using the 'checkrestart' command. A combination of unattended-upgrades and periodic checkrestart runs makes my life as a debuntu admin much easier. Note: Yes, I know how many environments this doesn't apply to. But if one person whose environment it does apply to discovers the joy of 'checkrestart' as a result of this comment, it was still worth typing out :D