Unable to access locations or initiatives in admin module about suma HOT 17 CLOSED

Hi Mark,

Thanks for reaching out about Suma. This isn't something we've seen before,
so please bear with us as we explore possibilities. A few questions:

1. Could you clarify one point? Are you able to get into the admin tools at
   all or is the redirect happening after logging into the admin tools and
   attempting to visit a sub page?

2. During installation and configuration, did you happen to create a
   session.yaml file? See
   https://github.com/cazzerson/Suma/blob/master/service/config/session_example.yaml

Thanks,

Bret

On Mon, Apr 11, 2016 at 8:53 AM, markparis [email protected] wrote:

I have started the process of installing Suma on my Windows 2008 r2 server
here at Brandeis so that our Access Services team can evaluate and test it
for future headcount usage among other things. I have completed the install
process to the point that I can access the client, analytics module, and
the administrative module. However, whenever I log into the administrative
module and try to add locations or initiatives, I get kicked back to the
administrative login screen. Is there an aspect of the configuration
process that I have missed? Any assistance is greatly appreciated.

Kind regards,
Mark Paris

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#45

from suma.

Hi Bret,
Thanks for the quick follow-up! Regarding 1 above, I am able to log into the admin tools. I can see the menu. It doesn't seem to matter whether I click Edit Locations, Edit Initiatives, or Direct JSON Import...I get kicked back to the login screen regardless.

Regarding 2, I did create a sesion.yaml file based on the example provided (I kept all of the defaults in the example because I did not customize the location of the sumaserver).

Thanks,
Mark

from suma.

Hi Mark,

Would you mind e-mailing me your session.yaml file? [email protected]

Thanks!

Bret

On Mon, Apr 11, 2016 at 2:39 PM, markparis [email protected] wrote:

Hi Bret,
Thanks for the quick follow-up! Regarding #1
#1 above, I am able to log into
the admin tools. I can see the menu. It doesn't seem to matter whether I
click Edit Locations, Edit Initiatives, or Direct JSON Import...I get
kicked back to the login screen regardless.

Regarding #2 #2, I did create a
sesion.yaml file based on the example provided (I kept all of the defaults
in the example because I did not customize the location of the sumaserver).

Thanks,
Mark

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#45 (comment)

from suma.

Hi Mark,

Since sessions.yaml is an optional file, could you remove the session.yaml
file and try to create some initiatives and locations without a
session.yaml? This would at least confirm if the issue is with the cookies
or something else.

Thanks,

Bret

On Mon, Apr 11, 2016 at 2:41 PM, Bret Davidson [email protected] wrote:

Hi Mark,

Would you mind e-mailing me your session.yaml file? [email protected]

Thanks!

Bret

On Mon, Apr 11, 2016 at 2:39 PM, markparis [email protected]
wrote:

Hi Bret,
Thanks for the quick follow-up! Regarding #1
#1 above, I am able to log
into the admin tools. I can see the menu. It doesn't seem to matter whether
I click Edit Locations, Edit Initiatives, or Direct JSON Import...I get
kicked back to the login screen regardless.

Regarding #2 #2, I did create
a sesion.yaml file based on the example provided (I kept all of the
defaults in the example because I did not customize the location of the
sumaserver).

Thanks,
Mark

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#45 (comment)

from suma.

Thanks, Bret. I renamed session.yaml to _session.yaml, logged in to the admin module and clicked on Edit Locations. When I did that I got a 500 Internal Server Error.

from suma.

OK, two ideas:

1. Double check that the suma log exists and is writable by the application.

2. Double check the file formatting of the config files using something
   like http://www.yamllint.com/

3. If those don't work, could you send me your other config files for the
   server (suma/service/web/config and suma/service/config)? Please be sure to
   remove any DB passwords. [email protected]

Thanks,

Bret

On Tue, Apr 12, 2016 at 8:15 AM, markparis [email protected] wrote:

Thanks, Bret. I renamed session.yaml to _session.yaml, logged in to the
admin module and clicked on Edit Locations. When I did that I got a 500
Internal Server Error.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#45 (comment)

from suma.

After checking the suma log, it does not exist. I have checked the apache logs to ensure they are being written as expected, and they are, so I don't think there is a permissions issue, but I'm not 100% certain.

I have also checked the config file formats using www.yamllint.com as recommended and they check out just fine as far as the syntax.

I will email those files to you momentarily for a more thorough review.

Thanks,
Mark

from suma.

Hi Mark,

Just following up on one point. Have you created the suma log? That file
must exist for the suma server to function and would be in addition to the
apache logs. Also, in the config file that sets the path to the suma server
log, I noticed that there wasn't a space after the key for the path or
name. That might be something to check as well.

Thanks!

Bret

On Tue, Apr 12, 2016 at 11:38 AM, markparis [email protected]
wrote:

After checking the suma log, it does not exist. I have checked the apache
logs to ensure they are being written as expected, and they are, so I don't
think there is a permissions issue, but I'm not 100% certain.

I have also checked the config file formats using www.yamllint.com as
recommended and they check out just fine as far as the syntax.

I will email those files to you momentarily for a more thorough review.

Thanks,
Mark

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#45 (comment)

from suma.

Hi Bret,

I didn’t realize that I needed to manually create the log file. For some
reason, I thought the server would create it if it didn’t already exist and
was given a path. I went ahead and created the .log file specified in
config.yaml. I also corrected the spacing issue. After restarting apache
(not sure if I needed to do that or not, but it wouldn’t hurt), I am still
getting kicked out when clicking on Edit Locations.

I also checked the new log file to see if there is an entry, but nothing
had been written to the file.

Thanks,

Mark

From: Bret Davidson [mailto:[email protected]]
Sent: Wednesday, April 13, 2016 8:13 AM
To: cazzerson/Suma [email protected]
Cc: markparis [email protected]
Subject: Re: [cazzerson/Suma] Unable to access locations or initiatives
in admin module (#45)

Hi Mark,

Just following up on one point. Have you created the suma log? That file
must exist for the suma server to function and would be in addition to the
apache logs. Also, in the config file that sets the path to the suma server
log, I noticed that there wasn't a space after the key for the path or
name. That might be something to check as well.

Thanks!

Bret

On Tue, Apr 12, 2016 at 11:38 AM, markparis [email protected]
wrote:

After checking the suma log, it does not exist. I have checked the apache
logs to ensure they are being written as expected, and they are, so I
don't
think there is a permissions issue, but I'm not 100% certain.

I have also checked the config file formats using www.yamllint.com as
recommended and they check out just fine as far as the syntax.

I will email those files to you momentarily for a more thorough review.

Thanks,
Mark

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#45 (comment)

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#45 (comment)

from suma.

Hi Mark,

Is the logfile writable by the application? You may need to open up the
permissions a bit.

Thanks!

Bret

On Wed, Apr 13, 2016 at 8:32 AM, markparis [email protected] wrote:

Hi Bret,

I didn’t realize that I needed to manually create the log file. For some
reason, I thought the server would create it if it didn’t already exist and
was given a path. I went ahead and created the .log file specified in
config.yaml. I also corrected the spacing issue. After restarting apache
(not sure if I needed to do that or not, but it wouldn’t hurt), I am still
getting kicked out when clicking on Edit Locations.

I also checked the new log file to see if there is an entry, but nothing
had been written to the file.

Thanks,

Mark

From: Bret Davidson [mailto:[email protected]]
Sent: Wednesday, April 13, 2016 8:13 AM
To: cazzerson/Suma [email protected]
Cc: markparis [email protected]
Subject: Re: [cazzerson/Suma] Unable to access locations or initiatives
in admin module (#45)

Hi Mark,

Just following up on one point. Have you created the suma log? That file
must exist for the suma server to function and would be in addition to the
apache logs. Also, in the config file that sets the path to the suma server
log, I noticed that there wasn't a space after the key for the path or
name. That might be something to check as well.

Thanks!

Bret

On Tue, Apr 12, 2016 at 11:38 AM, markparis [email protected]
wrote:

After checking the suma log, it does not exist. I have checked the apache
logs to ensure they are being written as expected, and they are, so I
don't
think there is a permissions issue, but I'm not 100% certain.

I have also checked the config file formats using www.yamllint.com as
recommended and they check out just fine as far as the syntax.

I will email those files to you momentarily for a more thorough review.

Thanks,
Mark

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#45 (comment)

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#45 (comment)

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#45 (comment)

from suma.

Hi Mark,

Just following up on this. In addition to verifying that the log is writable, it might be worth double checking the path in your config file that points to the sumalog.

Thanks,

Bret

from suma.

Hi Bret,
Thanks for the follow-up. I have scheduled a check-in with our systems group to double-check on these items. I am an admin on the server, but perhaps there is a setting that I have missed. They will be able to help me to figure that out.

Thanks,
Mark

from suma.

Hi Mark,

Great, please let me know how it works out and if there is anything else we
can try to assist with.

Best,

Bret

On Thu, Apr 14, 2016 at 4:13 PM, markparis [email protected] wrote:

Hi Bret,
Thanks for the follow-up. I have scheduled a check-in with our systems
group to double-check on these items. I am an admin on the server, but
perhaps there is a setting that I have missed. They will be able to help me
to figure that out.

Thanks,
Mark

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#45 (comment)

from suma.

Hi Bret,

I just wanted to follow-up. After making a few adjustments, I can confirm that the error log is being written to the server as expected. I have botched the login to the admin tools a few times to test it, and the log is successfully recording those failures. However, the same problem is persisting.

Could it be that there are known problems with Apache 2.4 (64-bit), PHP 7 (64-bit) and MySQL 5.7 (64-bit) on Windows Server 2008 R2?

Thanks,
Mark

from suma.

Hi Mark,

Thanks for following up. I'm running out of ideas, but another thing to check to resolve the 500 error would be your database access including the database name, user name, password, port, and host.

Thanks,

Bret

from suma.

Hi Mark,

Any updates on your progress?

Bret

from suma.

Hi Mark,

We had another issue come in similar to yours that was solved by ensuring the PDO extension for PHP. Please see Issue #64. Hope that helps. I'm going to close this issue but please feel free to re-open if necessary.

Bret

from suma.