Skip to first unread message

EdderShredder

unread,
Feb 4, 2019, 10:22:13 AM2/4/19
to AtoM Users
Hello.

Our atom server was running up until today when it has started giving a 500 error.

We are using 2.2 or 2.3 on Ubuntu 16.04. I cannot check the version as I am getting
Unable to open PDO connection [wrapped: SQLSTATE[HY000] [1045] Access denied for user 'root'@'localhost' (using password: NO)].

This seems to be the error in logs as well when i type
sudo tail -f /var/log/nginx/error.log.

request: "GET /index.php/informationobject/browse?levels=221&places=4373&showAdvanced=1&sort=alphabetic&topLod=0 HTTP/1.1", upstream: "fastcgi://unix:/run/php7.0-fpm.atom.sock:",

This happened out of the blue.
Server has been running for months without issue.

I have access to terminal and filesystem.

Dan Gillean

unread,
Feb 4, 2019, 11:16:35 AM2/4/19
to ICA-AtoM Users
Hi Ed, 

First thing I would check would be the filesystem permissions. For AtoM to work as expected, the www-data user needs to have CRUD (create, read, update, delete) permissions on all files and directories below the root installation directory (generally at /usr/share/nginx/atom). 

I would suggest you try resetting these, restarting services, and see if this resolves the issue. Assuming you've followed our recommended installation documentation, you can reset the permissions with the following command: 
You will probably want to restart PHP-FPM and memcached, and clear the application cache as well after. Let us know if that helps. 

I will point out that while 2.3 has been tested and documented to work with Ubuntu 16.04, we never did test version 2.2 with 16.04 and PHP7, so it's also possible that this could be causing issues. 

Note that (depending on how badly the permissions are screwed up) there is a task that will allow you to check the full AtoM version of your installation via the command-line - see: 

Let us know if that helps. 

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-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.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/f1e3c12d-77de-4bfd-b949-d1074ca4e3ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Dan Gillean

unread,
Feb 4, 2019, 12:27:18 PM2/4/19
to ICA-AtoM Users
Hi again, 

One of our developers suggested that this might actually be a database connection issue. Have you changed anything in in the MySQL server recently? Perhaps tried to change the password for the root user?

Note that in our installation documentation we recommend creating and using a different MySQL user than the root user. See this, and an example of how to create a different user, here: 
If you need to check or add/change the database user and password without having to run the web installer again, you could do this by modifying the credentials in the config/config.php file. See: 
Again, remember to restart services, esp. PHP-FPM, and clear your application cache, after making changes to the configuration files. 

Cheers, 

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

EdderShredder

unread,
Feb 4, 2019, 12:43:44 PM2/4/19
to AtoM Users
Regarding permissions I chown the atom directory and restarted php and nothing happened.
I am using 2.3 and 16.04

I still cannot run the get version command.

But....my config.php seems to have been changed yesterday?

// auto-generated by sfInstall::configureDatabase()
// date: 2019/02/03 13:34:40

return array (
 
'all' =>
  array
(
   
'propel' =>
    array
(
     
'class' => 'sfPropelDatabase',
     
'param' =>
      array
(
       
'encoding' => 'utf8',
       
'persistent' => true,
       
'pooling' => true,
       
'dsn' => 'mysql:dbname=atom;port=3306',
       
'username' => 'root',

ETC


Why would this happen without my intervention? Will I change the username to "atom" and save as I have installed according to documentation?

Dan Gillean

unread,
Feb 4, 2019, 1:03:44 PM2/4/19
to ICA-AtoM Users
Hi Ed, 

Regarding your questions: 

Why would this happen without my intervention? 

I am not sure! It shouldn't. It looks as if the web installer was run again. That shouldn't be possible for public users to initiate in a properly deployed site. You can test this on your site by making sure you are logged out, and then adding the following to the base URL of your site: 

/index.php/sfInstallPlugin/configureDatabase

If this opens the web installer when you are viewing the site as a public user, then something's wrong - let us know if this is the case. Otherwise, I assume that someone with login credentials to your site initiated the web installer or made some other kind of change? There are currently no known bugs I can think of that display this kind of behavior. 


Will I change the username to "atom" and save as I have installed according to documentation?

See my previous follow-up reply. I am neither a developer nor system administrator, but I think that if you want to create an atom user, first you should create the user via the MySQL command-line. In this example, we are creating a user name atom with a password of 12345: 
  • mysql -h localhost -u root -p -e "GRANT ALL ON atom.* TO 'atom'@'localhost' IDENTIFIED BY '12345';"
Now in your config file, you can change the user to AtoM - but you will also want to make sure you have a line for the password as well: 

  array (
    'propel' => 
    array (
      'class' => 'sfPropelDatabase',
      'param' => 
      array (
        'encoding' => 'utf8',
        'persistent' => true,
        'pooling' => true,
        'dsn' => 'mysql:host=localhost;port=3306;dbname=atom;charset=utf8',
        'username' => 'atom',
        'password' => '12345',
      ),
    ),

Let us know if that helps. 
Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory

EdderShredder

unread,
Feb 4, 2019, 1:14:37 PM2/4/19
to AtoM Users
Yeah we are back up after fixing the config.

I don't see how this was possible as I am the only one with access and the server is on lockdown with passphrase pubkeys, passwords etc.
the index.php/sfInstallPlugin/configureDatabase does not function without login.

EdderShredder

unread,
Feb 4, 2019, 1:16:46 PM2/4/19
to AtoM Users
If you need logs etc off me just tell me where they are located and where to send them.

Karl Goetz

unread,
Feb 4, 2019, 5:26:56 PM2/4/19
to ica-ato...@googlegroups.com
I will avoid commenting on most of the discussion but thought I’d cover a couple of missing points.

Firstly, AtoM version is hard coded in to one of the qubit files.
```
root@atom-test-web:/data/sites/atom/current# grep -r 2\.4\.0 apps/qubit/config/qubitConfiguration.class.php
    VERSION = '2.4.0';
```

Secondly, could I suggest checking your web server logs for configureDatabase? You should see something like this:
```
root@atom-test-web:/data/sites/atom/current# zgrep configure /var/log/nginx/* 
/var/log/nginx/access.log:[IP address] - - [04/Feb/2019:22:18:01 +0000] "GET /index.php/sfInstallPlugin/configureDatabase HTTP/1.1" 200 3536 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0.2 Safari/605.1.15"
```

If you have a hit around 2019/02/03 13:34:40 (plus or minus UTC offset) someone at [IP address] may have fiddled with your db.

Karl.

To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@http://googlegroups.com.
--
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-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.

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

-- 
Karl Goetz,  Senior Library Officer (Library Systems)
University of Tasmania, Private Bag 25, Hobart 7001
Available Tuesday, Wednesday, Thursday



University of Tasmania Electronic Communications Policy (December, 2014).
This email is confidential, and is for the intended recipient only. Access, disclosure, copying, distribution, or reliance on any of it by anyone outside the intended recipient organisation is prohibited and may be a criminal offence. Please delete if obtained in error and email confirmation to the sender. The views expressed in this email are not necessarily the views of the University of Tasmania, unless clearly intended otherwise.

Ed

unread,
Feb 5, 2019, 3:47:29 AM2/5/19
to ICA-AtoM Users
Thanks Karl I'll get on that when I can and post results. 

You received this message because you are subscribed to a topic in the Google Groups "AtoM Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ica-atom-users/XN-IRUUhzM0/unsubscribe.
To unsubscribe from this group and all its topics, 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.

Dan Gillean

unread,
Feb 5, 2019, 10:10:02 AM2/5/19
to ICA-AtoM Users
Karl, your contributions are always insightful and welcome - thanks!

Ed, as you can see in Karl's examples, Nginx has an access log - if it is enabled in your installation, it is usually found at /var/log/nginx/access.log

If you can't find it there, you can check to see if it's enabled, and the location it is stored, by looking for the access_log directive in /etc/nginx/nginx.conf

Cheers, 

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

EdderShredder

unread,
Feb 5, 2019, 11:14:21 AM2/5/19
to AtoM Users
Looking through a wall of logs now.

No GET /index.php/sfInstallPlugin/configureDatabase HTTP/1.1" 200 3536 around the time of the config autogenerate.
Although I do see a lot of requests from bots and the like all through the log for that address.

Do the numbers in Karl's example @ (GET /index.php/sfInstallPlugin/configureDatabase HTTP/1.1" 200 3536) denote a success accessing that page?


Dan Gillean

unread,
Feb 5, 2019, 11:18:31 AM2/5/19
to ICA-AtoM Users
Hi Ed, 

I'm not actually sure about the meaning of the "3536" part, but yes, an HTTP 200 code generally means success. See: 

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-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.

EdderShredder

unread,
Feb 5, 2019, 2:42:28 PM2/5/19
to AtoM Users
 My earliest finding of sfplugin address access is early Sunday.
207.46.13.244 - - [03/Feb/2019:06:23:14 +0000] "GET /index.php/sfInstallPlugin/configureDatabase HTTP/1.1" 200 1866 "-" "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)"

He got a code 200. And I doubt the bingbot started this.
I am stumped.

Accessing the qubit_worker.log gives me the first instance of our error @ Saturday.
before the config was apparently auto generated.
Feb 02 21:54:00 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:54:05 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:54:11 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:54:17 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:54:23 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:54:29 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:54:34 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:54:40 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:54:46 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:54:51 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:54:57 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:55:02 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:55:08 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:55:13 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:55:20 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:55:25 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:55:31 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:55:36 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:55:42 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:55:47 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:55:52 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:55:58 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:56:04 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:56:09 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:56:15 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:56:20 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:56:26 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:56:32 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:56:37 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:56:42 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:56:48 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:56:53 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
Feb 02 21:56:59 symfony [err] {PropelException} Unable to open PDO connection [wrapped: SQLSTATE[HY000] [2002] No such file or directory]
ETC

These errors continue to generate every time the site is accessed until Feb 04 10:11:16 for 23642 lines of the log.

Dan Gillean

unread,
Feb 6, 2019, 11:18:04 AM2/6/19
to ICA-AtoM Users
Hi Ed, 

One thing to note here: in this case, the 200 success status doesn't necessarily mean that they accessed the web installer. AtoM returns a valid web page when you try to access /index.php/sfInstallPlugin/configureDatabase - it just happens to be a webpage with a permission denied message:

permission-denied.png

I tried using cURL against the AtoM public demo site for this page, as well as in my local Vagrant box. In both cases, I can see this permission denied message in the returned HTML, and when I check the access logs, I see the cURL request received a 200 status.

All this to say: I'm not yet fully convinced that the Bing bot managed to access your web installer and mess with the database configuration settings. I will keep checking with our team to see if they have any further ideas. 

If you remain worried about this, you might consider adding your own custom authentication rules for the web installer paths,  and adding a robots.txt directive, so at least bots that respect the directive (like Bing, generally) will not try to access the specified paths. I've not tried the first, but we've definitely added custom robots.txt directives when certain bots have started hitting client sites unreasonably hard, which has helped. 

Cheers, 
--
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-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.

Karl Goetz

unread,
Feb 6, 2019, 5:00:02 PM2/6/19
to ica-ato...@googlegroups.com
Hi Dan,
Would you be open to me raising a bug about that behaviour of returning a 200? The HTTP standard provides for ‘denied’ codes so using 200 seems incorrect.

Karl.

On 7 Feb 2019, at 3:17 am, Dan Gillean <d...@artefactual.com> wrote:

Hi Ed, 

One thing to note here: in this case, the 200 success status doesn't necessarily mean that they accessed the web installer. AtoM returns a valid web page when you try to access /index.php/sfInstallPlugin/configureDatabase - it just happens to be a webpage with a permission denied message:


For more options, visit https://groups.google.com/d/optout.
-- 
Karl Goetz,  Senior Library Officer (Library Systems)
University of Tasmania, Private Bag 25, Hobart 7001
Available Tuesday, Wednesday, Thursday

Dan Gillean

unread,
Feb 6, 2019, 5:39:47 PM2/6/19
to ICA-AtoM Users
Hi Karl, 

I agree. I've gone ahead and filed a bug report in our official issue tracking system, here: 
Feel free to suggest changes to it!

Cheers, 

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


Karl Goetz

unread,
Feb 6, 2019, 5:49:52 PM2/6/19
to ica-ato...@googlegroups.com
Hi Dan,
Looks great, thanks!


For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages