404 when trying to complete account activation

[Poorchop]

Issue details

I'm unable to finish my account activation. Immediately after trying to create an account, I get a 50x error, but I'm still able to receive the activation email. However, when I click the activation link, I receive a 404. There's no useful information whatsoever in the logs pertaining to this issue, only the following:

PHP message: PHP Warning:  DateTime::createFromFormat(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone.

For the record, I've set the timezone in my php.ini to the server's timezone. I doubt that this issue is related to the system time though.

Environment

• wallabag version (or git revision) that exhibits the issue:
  • Presumably 2.0.4
• How did you install wallabag? Via git clone or by downloading the package?
  • Downloaded from http://wllbg.org/latest-v2-package on 21/5/2016 (today)
• Last wallabag version that did not exhibit the issue (if applicable):
  • Version 1 (can't remember exact version number, was last installed over a year ago)
• php version:
  • 5.6.21
• OS:
  • CentOS 7 x86_64
• type of hosting (shared or dedicated):
  • VPS
• which storage system you choose at install (SQLite, MySQL/MariaDB or PostgreSQL):
  • SQLite

Steps to reproduce/test case

1. Download the latest v2 package
2. Download the latest EPEL 7 release as well as Remi's PHP repo, then enable PHP 5.6 in /etc/yum.repos.d/remi.repo
3. Install nginx and PHP
4. Create /var/lib/php/nginx-session/ and make it writable
5. Change user and group to nginx in php.ini
6. Access your wallabag via the web browser and create an account
7. Click on the activation link after receiving the email
8. Check wallabag_error.log for details

I also had a much harder time just getting to this point compared to installing v1. I thought v2 was supposed to simplify installation but this is the hardest time that I've ever had installing anything.

• When I tried using composer, installation failed.
• The first time I tried manual installation with the latest v2 package, it created a read-only folder than was impossible to delete even as super user and my OS somehow became unbootable afterwards.
• When I finally made progress, it seemed that new folders are constantly generated in various wallabag subdirectories, like wallabag/var and wallabag/vendor. In v1, I only had to to make assets, cache, db, and inc writable. Now I can't figure out what needs write access and setting SELinux contexts is even worse.

v2 looks beautiful in the screenshots and seems to offer much more than v1, but installation is infinitely harder for me.

[j0k3r]

Does your server allow sending email?
Any more information in var/log/prod.log?

[Poorchop]

Does your server allow sending email?

Yes - I never explicitly installed it myself but postfix was already configured on the system, so I was surprised when I received the email.

Any more information in var/log/prod.log?

A whole lot of information - it was tough to parse but I noticed another error with write access. I disabled SELinux and quickly just set chmod 775 on the entire wallabag directory. I redid the $vhost.conf and combined some old rules with new ones from the v2 docs. Finally everything worked. I'm not sure if it will help you but I could try to parse and post relevant information from prod.log if you're interested.

---

It seems like the biggest issue was setting write access on all of the appropriate folders. Also maybe I'm mistaken, but it seemed like new directories were being generated every time I tried accessing the webapp. I just kept constantly setting 775 recursively and eventually gave up with SELinux.

Is there any way that we could just get a list of folders that need write access? If the cache and log folders could also be specified, that would help with setting the proper SELinux contexts as well.

[j0k3r]

As far as I know, only var/log and var/cache need write access. And data folder too if you are using SQLite.

[Poorchop]

Are any new folders generated after the initial extraction from the archive? I remember setting 775 recursively quite a few times and I still kept getting write access errors. This was even with SELinux disabled while I was testing. I'll have to try again with installation. I'll set up another instance and try from scratch again.

I also take it that an MTA is a requirement so that we can receive the confirmation email.

[Poorchop]

It took me nearly an entire day but I set up a clean VPS and I figured out the following:

• /var/www/wallabag must be owned by nginx:nginx
• /var/lib/php/nginx-session or /var/lib/php/session must be owned by nginx:nginx (not root:[httpd] as per default)
• /var/www/wallabag/data and /var/www/wallabag/var both need chmod 775

The following SELinux rules are needed:

Path	Context
/var/www/wallabag/data(/.*)?	httpd_sys_rw_content_t
/var/www/wallabag/var/logs(/.*)?	httpd_log_t
/var/www/wallabag/var/cache(/.*)?	httpd_cache_t
/var/www/wallabag/var	httpd_sys_rw_content_t

I think this is also needed at the very least:

setsebool -P httpd_can_sendmail 1

I also had these rules set, some of them from other webapps that I'm running:

setsebool -P httpd_can_network_connect 1
setsebool -P httpd_can_network_connect_db 1
setsebool -P httpd_can_network_memcache 1

Lastly, don't forget to allow smtp through your firewall.

I think that should cover everything. I know not everyone has SELinux enabled and that was half of my problems, but hopefully this helps somebody else in the future. Also, I confirmed that /var/cache and /var/logs are indeed generated after successfully launching the webapp. This is why wallabag/var needs to be writable.

[nicosomb]

Hello @Poorchop,

Thank you for your feedback.
Maybe we need to update our installation documentation with your last post.

Can you open a new pull request please?

[Poorchop]

Hi @nicosomb, I'd be happy to propose some additions to the documentation but my problems mostly pertain to a very specific environment, namely CentOS 7 with nginx and SELinux enabled and installing via "latest-v2-package" instead of using the recommended way with git and composer. Also, I'm not 100% sure if all of my above suggestions are best practice and secure. I'll try my best to modify the documentation but hopefully else someone can review my changes carefully and guide me if they don't agree with my suggestions.