[nycbug-talk] fave BSD tips/tricks?

Brian Cully bcully at gmail.com
Wed Aug 26 15:22:15 EDT 2009


On 26-Aug-2009, at 14:53, Jerry B. Altzman wrote:
> on 8/26/2009 12:42 PM Brian Cully said the following:
>> On 26-Aug-2009, at 10:29, Jerry B. Altzman wrote:
>>> Why are developers on production servers?
>>    Because sometimes a sysadmin doesn't have enough knowledge of a  
>> complex piece of software to figure out why things are going awry  
>> in production. Sometimes problems only crop up in production.  
>> Sometimes your developers are your sysadmins. Sometimes sysadmins  
>> prefer these tools or have no other suitable CLI substitute.
>
> That's right...so you take dumps over, or you sit with them...on a  
> not-the-production-server machine.

	Dumps? You're off it. Not every piece of software produces a core  
dump, let alone a usable one. Even if it does, sometimes you can only  
catch a bug in production unless you're willing to wait until the next  
ice age catch it you're "right" way. Like it or not, being able to  
debug in real-time as the problem occurs is an enormous time-saver a  
lot of the time. And when your system is breaking in production you  
don't have a lot of time to fix it. And please, don't start on about  
version control. I've had systems where a hardware rollout has broken  
servers and that's not exactly something you can just roll back.

> I'm not talking about everything-on-a-server. I'm talking about, you  
> know, real production environments with real change control and  
> whatnot.

	FSVO "real." Elitism, I hardly knew ye.

>> do the actual development/compilation somewhere else. I just don't  
>> see the harm except for niche environments. Why should I fret about  
>> having X take up a hundred megs of space even if I don't use it  
>> when I have a terabytes? And odds are good that at some point in  
>> the future, if I use the box long enough, I'll want X in a crunch.
>
> More straw -- I never mentioned saving disk space.

	So what's the harm? Where's the attack vector on a non-s*id binary  
that no one ever runs? Where's the attack vector when it *is* run,  
assuming I have normal user privs? How does having X clients installed  
on my box give an attacker more surface area? How is it different than  
having vi installed on my box? I'm not even talking about compilers,  
just standard user-land no-privs tools.

	FWIW, I actually agree about the compilers to some degree, but for  
different reasons. I don't install them because I don't want people  
compiling code on the server outside of source control and build  
mechanisms, not because it grants me security (which it doesn't in any  
meaningful sense). Even that's basically impossible these days since a  
lot of code isn't compiled (ruby, php, &c). So perhaps ruby shouldn't  
be installed either.

-bjc



More information about the talk mailing list