[Labs-l] No space left on device?

[Petr Bena]

For example right now everyone can fill up /var/tmp or /tmp to 100%
making all filesystems on any server unwritable. That is severe
security hole that basically allows any regular user to fuck up server
of their choice (except for boxes that aren't directly accessible).
This /should/ be fixed.

On Thu, May 1, 2014 at 9:32 AM, Petr Bena <benapetr at gmail.com> wrote:
> One more reason to keep /var/log in separate lvm volume as we had on
> old boxes before migration. I would set it up again but for some
> reason I feel like people are opposed to do that for unknown reasons.
> However on real production systems in my work the servers have
> zillions of separate lvm volumes for everything possible so that these
> subsystems are so isolated from each other that it is nearly
> impossible to affect everyone by doing things like this.
>
> On Wed, Apr 30, 2014 at 11:34 PM, Tim Landscheidt
> <tim at tim-landscheidt.de> wrote:
>> (anonymous) wrote:
>>
>>> I was tracking down why my PHP session data is lost, and I found the
>>> following warning in the error.log:
>>
>>> 2014-04-30 19:27:03: (mod_fastcgi.c.2701) FastCGI-stderr: PHP Warning:
>>>  Unknown: write failed: No space left on device (28) in Unknown on
>>> line 0
>>> PHP Warning:  Unknown: Failed to write session data (files). Please
>>> verify that the current setting of session.save_path is correct
>>> (/var/lib/php5) in Unknown on line 0
>>
>>> So, does that simply mean the webservers' drive is full, or that my
>>> storage is full? Or should I point the  session.save_path somewhere to
>>> my data storage?
>>
>> This was caused by me flooding /var/log/auth.log with sudo
>> logs; sorry, I'll fix that immediately.  I filed
>> https://bugzilla.wikimedia.org/64683 for tracking.
>>
>> Tim
>>
>>
>> _______________________________________________
>> Labs-l mailing list
>> Labs-l at lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/labs-l