elrido / ZeroBin

This Project has been renamed and moved to
https://github.com/PrivateBin/PrivateBin
Other
85 stars 8 forks source link

Can no longer create paste when using "db" model. #22

Closed Hexalyse closed 8 years ago

Hexalyse commented 9 years ago

This is really really strange. Everything was working fine a few minutes agos. I just merged your new commits, recloned the fork on my serveur for a clean install, and now I can't use the "database (SQLite)" model. When I use the standard data model on disk, everything works fine (so there are no write permissions problem, nginx has write access to data dir), but when switching back to "zerobin_db", I get a Could not create paste: Error saving paste. Sorry.

elrido commented 9 years ago

If you can exclude any issues with the permissions of the sqlite file, try downloading it and check if you can open it with an alternative tool, i.e. SQLiteStudio or similar to check if the DB is corrupt.

I would not suggest to use sqlite on a public installation and mainly use it locally for unit testing. I am not sure if sqlite handles concurrency very well. For ease of installation I left the data-file model as the default.

Hexalyse commented 9 years ago

Wouldn't SQLite be better than filesystem model, at least ? I'll consider creating a MySQL database for ZeroBin pretty soon because I might consider letting my installation publicly available indeed. The fact ist that I have completely deleted the .sq3 file, and it seems like it can't create it (and I'm not into PHP at all, so I don't even know if I can debug it or not).

elrido commented 9 years ago

Ok, that definitely sounds like a permission problem. Do you know as what user and group the webserver or php-process runs on your host? Check if that user can create files in the folder that the .sq3 file is located. Here is php snippet to test that:

<?php
// change PATH depending on where this file is located relative to the data dir
define('PATH', '');
error_reporting( E_ALL | E_STRICT ); // to force display of file access errors
header("Content-Type:text/plain"); // in case you run this via webserver
echo 'permissions of data dir: ', substr(sprintf('%o', fileperms(PATH . 'data')), -4), PHP_EOL;
echo 'owner/group of data dir: ', posix_getpwuid(fileowner(PATH . 'data')), '/', posix_getgrgid(filegroup(PATH . 'data')), PHP_EOL;
echo 'is db.sq3 writable: ', (is_writable(PATH . 'data' . DIRECTORY_SEPERATOR . 'db.sq3') ? 'yes' : 'no'), PHP_EOL;
echo 'trying create new file: ';
$result = file_put_contents(PATH . 'data' . DIRECTORY_SEPERATOR . 'test.txt', 'test');
echo ($result === false ? 'error writing to file' : 'success'), PHP_EOL;

If it is indeed a permission problem, make sure that the owner or group of the webserver or php-process has write permissions (w flag) on the data folder. I have seen such issues happening on webhosters where the user/group you upload your files with (by SSH/(S)FTP) is not the same as those of the webserver or php-process.

For production servers with more then one person at a time creating pastes or commenting I would strongly suggest to use a DB service like MySQL or Postgres. SQLite is known to have concurrency problems and in the event of a crash (or backup restore) the file can end up in an inconsistent state.

Hexalyse commented 9 years ago

It's very unlikely to be a permission problem, as it has always worked before, and suddenfly stopped working. But nothing has changed on the server (the user running the nginx processes is www-data and it's the owner of the /data/ folder, with w permission).

But thank you for the information about SQLite, I didn't know there were such problems. I'll definitely switch to MySQL, then !

elrido commented 9 years ago

If you have some time, could you check if you still have these kinds of problems with sqlite (or mysql) in the current master version? I suspect that these issues might have been related to some of the issues I found and solved with the database layer recently.

elrido commented 8 years ago

Please feel free to reopen this issue, if it is not yet resolved in the current version.