Unable to sign into local AtoM instance and no log messages

[mmikit...@gmail.com]

Hello,

My AtoM environment is:

* Oracle Linux 7.4 (not able to change this)

* Nginx 1.10.2

* PHP 5.4.16 (latest Oracle Linux package; not able to change this)

* MySQL 5.5

* ElasticSearch 1.7.6

* Java 1.8

* AtoM 2.3.0

I am encountering two problems (one emerged from the other):

1) When I sign into my local AtoM instance with a valid username and password (user = ad...@myatom.localdomain ; password = admin), I am returned to the same screen with no indication that I am signed in (the "Log in" button in the top-right corner is still present). When I attempt to sign in with an invalid email, non-existent account, or invalid password, I receive an error message, as expected. However, when I supply the correct credentials, nothing appears to happen.

2) To diagnose the problem, I followed the logging configuration instructions at https://www.accesstomemory.org/en/docs/2.3/admin-manual/maintenance/logging/#maintenance-logging and put the application in Debug mode by modifying index.php. After fiddling with the factories.yml file and multiple "php symfony cc" commands, I see no messages in the log files. My factories.yml file is below, and you'll see that even with "debug", I see no messages. I confirmed that there are no write permission violations in /var/log/messages as well

Thank you in advance.

matt

Appendex: factories.yml

# You can find more information about this file on the symfony website:

# http://www.symfony-project.org/reference/1_4/en/05-Factories

prod:

  storage:

    class: QubitSessionStorage

    param:

      session_name: symfony

      session_cookie_httponly: true

      session_cookie_secure: true

test:

  storage:

    class: sfSessionTestStorage

    param:

      session_path: %SF_TEST_CACHE_DIR%/sessions

  response:

    class: sfWebResponse

    param:

      send_http_headers: false

  mailer:

    param:

      delivery_strategy: none

dev:

  mailer:

    param:

      delivery_strategy: none

  storage:

    class: QubitSessionStorage

    param:

      session_name: symfony

  logger:

    class: sfAggregateLogger

    param:

      level: debug

      loggers:

        sf_file_debug:

          class: sfFileLogger

          param:

            level: debug

            file: %SF_LOG_DIR%/%SF_APP%_%SF_ENVIRONMENT%.log

all:

  i18n:

    class: sfTranslateI18N

    param:

      cache:

        # class: sfAPCCache

        class: sfFileCache

        param:

          automatic_cleaning_factor: 0

          cache_dir: %SF_TEMPLATE_CACHE_DIR%

          lifetime: 86400

          prefix: %SF_APP_DIR%/template

  routing:

    class: QubitPatternRouting

    param:

      logging: false

      generate_shortest_url:            true

      extra_parameters_as_query_string: true

      # class: sfAPCCache

      cache: ~

  view_cache_manager:

    class: sfViewCacheManager

    param:

      cache_key_use_vary_headers: true

      cache_key_use_host_name:    true

  view_cache:

    # class: sfAPCCache

    class: sfFileCache

    param:

      automatic_cleaning_factor: 0

      cache_dir: %SF_TEMPLATE_CACHE_DIR%

      lifetime: 86400

      prefix: %SF_APP_DIR%/template

  user:

    class: myUser

    param:

      timeout: 1800 # Session timeout in seconds

  logger:

    class: sfAggregateLogger

    param:

      level: debug

      loggers:

        sf_file_debug:

          class: sfFileLogger

          param:

            level: debug

            file: %SF_LOG_DIR%/%SF_APP%_%SF_ENVIRONMENT%.log

[Dan Gillean]

Hi there, 

I'm going to ask a developer to take a look at this. In the meantime: 

• It's a long shot, but try restarting PHP-FPM and (if you are using it) memcached, in addition to clearing the application cache. Today we had a weird instance on the public demo site somewhat similar to this, that was resolved by restarting FPM. 
• Another long shot, but you can always try creating a new superuser (i.e. admin account) via the command line, to ensure it's not an issue with your username or password. See: 
• https://www.accesstomemory.org/docs/2.4/admin-manual/maintenance/cli-tools/#add-a-superuser-admin-account
  
• Did you try logging in after going into Debug mode? If this issue is because someone has activated the  IP restriction settings in the security panel,  then you might see this behavior, but it should be disabled when in Debug mode. 
• Another possibility is that someone has activated the requirement for SSL during login, but your site doesn't yet use HTTPS. You would see behavior similar to this in that case. 

Both of these options are described in the docs here: 

• https://www.accesstomemory.org/en/docs/2.4/user-manual/administer/settings/#security-panel
  

My suspicion is that it is one of the last 2 cases causing this issue - likely the last one (SSL setting turned on, but no SSL cert in place). If one of these issues these are the cause, then there might not be anything to see in the logs. You can always check the webserver logs to see if there's info, but I suspect not. 

I will see if a developer can let us know how you can check the database for this setting, and change it there if needed. 

Regards, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-atom-users@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/a11f10e1-ef14-4502-ad32-47b335aa4012%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mmikit...@gmail.com]

Hello Dan,

Always appreciate your quick, detailed and helpful responses. Thanks.

I should have stated that I am running AtoM 2.3.0 in a custom-built Docker container, so regarding your recommendations:

> 1)  It's a long shot, but try restarting PHP-FPM and (if you are using it) memcached, in addition to clearing the application cache. Today we had a weird instance on the public demo site somewhat similar to this, that was resolved by restarting FPM. 

PHP-FPM starts afresh whenever the container is instantiated. However, I did restart PHP-FPM after the container started with no success.

> 2) Another long shot, but you can always try creating a new superuser (i.e. admin account) via the command line, to ensure it's not an issue with your username or password. See: https://www.accesstomemory.org/docs/2.4/admin-manual/maintenance/cli-tools/#add-a-superuser-admin-account

I use the CLI to create the admin account when the container starts; I copied the plain text username (email) and password from the console to the "Log in" form. Still no success.

> 3) Did you try logging in after going into Debug mode? If this issue is because someone has activated the  IP restriction settings in the security panel,  then you might see this behavior, but it should be disabled when in Debug mode. 

I tried signing in with and without Debug mode enabled, with no success. Since I'm not able to sign into the site to check the IP restriction settings, can you direct me to a CLI command or the corresponding database table to confirm the state of the settings?

> 4) Another possibility is that someone has activated the requirement for SSL during login, but your site doesn't yet use HTTPS. You would see behavior similar to this in that case. 

SSL is enabled, though my browser generates warnings since the certificate was locally-generated. How can I see/change the SSL requirement via the CLI or database since I cannot sign into the web GUI?

Do you have any thoughts on my logging problems? Ideally I'd be able to trace the execution through the codebase; in the absence of any logging, I may resort to XDebug tracing.

Thanks,

matt 

To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.

[Jesús García Crespo]

Hi Matt,

Are you running more than one replica of AtoM behind a balancer? That would explain why you're having issues signing in to AtoM. By default AtoM persists session data in the user session. PHP stores its sessions on the filesystem.

The solution is to store session data in some common store like a database or other kind of data store (Redis, Memcache...).

You can change the session storage here: https://github.com/artefactual/atom/blob/qa/2.5.x/config/factories.yml#L4-L10. You can find other session storage implementations here: https://github.com/artefactual/atom/tree/qa/2.5.x/vendor/symfony/lib/storage. You could also implement your own by extending sfStorage.

Have you looked at our Docker setup? Our entry point invokes bootstrap.php which looks up the environment string and populates files like factories.yml. It uses QubitCacheSessionStorage, it's a long thread of subclasses but basically it ends up interfacing with sfCache to store the sessions in Memcache.

I'll try to respond your question about logging later.

To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-atom-users@googlegroups.com.

Visit this group at https://groups.google.com/group/ica-atom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/ec8c541c-b238-43db-aa03-463af58a7a92%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Jesús García Crespo,
Software Developer, Artefactual Systems Inc.
http://www.artefactual.com | +1.604.527.2056

[Jesús García Crespo]

Hi again,

 

Do you have any thoughts on my logging problems? Ideally I'd be able to trace the execution through the codebase; in the absence of any logging, I may resort to XDebug tracing.

Your factories.yml file seems fine unless I'm missing something. What is its location? My preferred location is apps/qubit/config/factories.yml so instead of changing config/factories.yml (which is part of the source code) I let the framework override the settings for me.

I'm not sure how to help you troubleshoot that. Perhaps you can experiment with the sfConsoleLogger logger which writes to the `php://stdout` stream. IIRC, FPM should be able to capture it and send it to the master process standard stream - although that may only happen if it's configured properly.

Another option is to go inside the cache/ folder and make sure the final config that Symfony is caching includes the factories as you expect. 

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/ec8c541c-b238-43db-aa03-463af58a7a92%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Jesús García Crespo,
Software Developer, Artefactual Systems Inc.
http://www.artefactual.com | +1.604.527.2056

[mmikit...@gmail.com]

Hello Jesús,

Thank you for the detailed and helpful response.

My current hypothesis is that my session and logging problems are symptoms of Symfony ignoring my factories.yml changes (you hinted at this in your last message). I ran the following test - please let me know your thoughts.

The factories.yml files are globally readable and there are no permission messages in /var/log/messages:

[root@50c5b0358a2c atom]# pwd

/usr/share/nginx/atom

[root@50c5b0358a2c atom]# ls -l config/factories.yml 

-rw-r--r-- 1 1000 1000 2087 Oct 13 16:31 config/factories.yml

[root@50c5b0358a2c atom]# ls -l apps/qubit/config/factories.yml 

-rw-r--r-- 1 1000 1000 219 Oct 13 16:32 apps/qubit/config/factories.yml

I created a logger as follows (log level debug; write to /tmp/testing.log):

[root@50c5b0358a2c atom]# cat apps/qubit/config/factories.yml 

all:

  logger:

    class: sfAggregateLogger

    param:

      level: debug

      loggers:

        sf_file_debug:

          class: sfFileLogger

          param:

            level: debug

            file: /tmp/testing.log

I remove all contents from the cache folder and run 'php symfony cc'

[root@50c5b0358a2c atom]# rm -rf cache/*

[root@50c5b0358a2c atom]# php symfony cc

[root@50c5b0358a2c atom]# ls -l cache/

total 52

-rw-r--r-- 1 root root 51053 Oct 13 16:40 project_autoload.cache

I then refresh the AtoM webpage (index.php) in my browser, and notice that my custom log file, /tmp/testing.log, is not in the cached configuration:

[root@50c5b0358a2c atom]# grep -ri 'testing\.log' cache/*

and the default, qubit_prod.log file is configured:

[root@50c5b0358a2c atom]# grep -ri 'qubit_prod\.log' cache/*

cache/qubit/prod/config/config_factories.yml.php:  'file' => '/usr/share/nginx/atom/log/qubit_prod.log',

Any ideas?

Thanks.

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/ec8c541c-b238-43db-aa03-463af58a7a92%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Jesús García Crespo,
Software Developer, Artefactual Systems Inc.
http://www.artefactual.com | +1.604.527.2056

[Jesús García Crespo]

I see, that's weird. I don't know why would that happen.

Try maybe to edit config/factories.yml instead, or both. Does the problem persist?

To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-atom-users@googlegroups.com.

Visit this group at https://groups.google.com/group/ica-atom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/400efa17-c1fe-4ed9-a397-6c4fe7649d48%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[mmikit...@gmail.com]

No change in behaviour after modifying config/factories.yml or both.

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/400efa17-c1fe-4ed9-a397-6c4fe7649d48%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Jesús García Crespo]

On Mon, Oct 16, 2017 at 10:40 AM, <mmikit...@gmail.com> wrote:

No change in behaviour after modifying config/factories.yml or both. 

Ok, I'm sorry to hear that.

This is a long shot but I realize our Docker image is based on `php:7-fpm-alpine`. That used to be an alias for php 7.0 but it's now based on php 7.1. That can be a problem.

I've just tried running AtoM with Compose (as documented here: https://www.accesstomemory.org/en/docs/2.5/dev-manual/env/compose/#dev-env-compose) and when I accessed to the dev frontend (`qubit_dev.php`) first thing I see is: `Warning: A non-numeric value encountered in /atom/src/vendor/symfony/lib/yaml/sfYamlInline.php(138) : runtime-created function on line 1
`. That could be caused by a backward-incompatible change in PHP 7.1, maybe? And perhaps this change here would fix it: https://github.com/LExpress/symfony1/commit/f738f43b2edf0c3d5fb5288c0ad0043d7baf09ab#diff-c49704e966bf205c8aaada6fdf850c66.

So you could try to build a new Docker image based on 7.0-fpm-alpine instead. I'm not sure if adding support for PHP 7.1 is on the radar, Dan probably knows this.

I'm sorry this is being so complicated. The vast majority of users are not using Docker so you're basically in highly untested territory, particularly in production environments.

[Dan Gillean]

Hi all, 

Non-backwards compatible changes in PHP 7.1 is something that came up recently in a different user forum thread, so it's something we are aware of, and try to address as we find it. It's unsponsored work, so not prioritized at the moment, but we remain hopeful we can identify the issues and complete changes by the 2.5 release. 

You can see mention of it in this issue ticket, which came out of the related forum thread: 

• https://projects.artefactual.com/issues/11542#note-3
  

For now, we're recommending that users stick with PHP7.0. 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

--

You received this message because you are subscribed to the Google Groups "AtoM Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-atom-users@googlegroups.com.

Visit this group at https://groups.google.com/group/ica-atom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CALavCbRLcCZSNDWgL78ZxW1%2B-n3YyaMx__MGHUy44kM5OiK_Rg%40mail.gmail.com.

[mmikit...@gmail.com]

Hi all,

It was the PHP version! After upgrading to PHP 7.0, I was able to sign in, and the factories.yml settings are found in the auto-generated factories file in the cache.

Note: I also tried PHP 7.1 with no success.

So, as per Dan's comments, stick with PHP 7.0!

matt

To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.

Visit this group at https://groups.google.com/group/ica-atom-users.