Skip to Content.
Sympa Menu

comanage-users - RE: [comanage-users] FCCN-COmanage problems

Subject: COmanage Users List

List archive

RE: [comanage-users] FCCN-COmanage problems


Chronological Thread 
  • From: "Pedro Severino" <>
  • To: "'Benn Oshrin'" <>
  • Cc: <>
  • Subject: RE: [comanage-users] FCCN-COmanage problems
  • Date: Wed, 22 Jul 2015 11:40:56 +0100
  • Organization: FCCN

Found it. The operating system does not see canvas or the other files as
symlinks, because of that the page isn't rendered and only the path of the
real symlink is showed. Looks like creating the symlinks myself everything
works just fine.

Thanks,

Pedro

-----Original Message-----
From:

[mailto:]
On Behalf Of Benn Oshrin
Sent: terça-feira, 21 de Julho de 2015 21:03
To: Pedro Severino
Cc:

Subject: Re: [comanage-users] FCCN-COmanage problems

Hi Pedro,

This certainly sounds like an Apache configuration issue (PHP, mod_rewrite,
FollowSymLinks, or something), but I can't reproduce it.

/canvas is implemented as a symlink to the View ../Standard/edit.ctp, so it
seems like your server is just rendering the symlink itself instead of
following it. Is there a parent directive somewhere overriding? If you look
at the symlink on the filesystem as the Apache user, can you read the
contents of the linked file? Also, I assume you have PHP enabled for the
directory?

Thanks,

-Benn-

On 7/21/15 12:26 PM, Pedro Severino wrote:
> Hello,
>
>
>
> I’m an employee of the Portuguese NREN, FCCN. We are thinking of doing
> some tests with COmanage, but we are having some issues with our setup.
>
> We already installed it and integrated COmanage with our IDP/SP
> development system.
>
>
>
> We are using CentOS release 6.6, PHP 5.3.3 and Apache/2.2.15 and
> everything looks fine at start. But when we try to explore a little
> more we get to pages were the content is not being rendered, like for
example:
>
> · Going to the webpage /registry/co_people/canvas/1 give us a
> normal looking page but the content only says “../Standard/edit.ctp”
>
>
>
> We did some digging around, but we couldn’t find the solution. We
> thought that it could be something about our apache configuration.
>
>
>
> Our apache conf file looks like this:
>
> <VirtualHost _default_:443>
>
> DocumentRoot "/var/www"
>
> ServerName vo-demo.fccn.pt
>
> # Use separate log files for the SSL virtual host; note that
> LogLevel
>
> # is not inherited from httpd.conf.
>
> ErrorLog /var/log/httpd/ssl_error_log
>
> TransferLog /var/log/httpd/ssl_access_log
>
> LogLevel warn
>
> SSLEngine on
>
> SSLProtocol all -SSLv2
>
> SSLCipherSuite
> ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
>
> SSLCertificateFile /etc/pki/tls/certs/vo-demo_fccn_pt.crt
>
> SSLCertificateKeyFile /etc/pki/tls/private/vo-demo_fccn_pt.key
>
> SSLCertificateChainFile /etc/pki/CA/certs/DigiCertCA.crt
>
>
>
> <Directory "/var/www/registry/">
>
> Options Indexes FollowSymLinks
>
> DirectoryIndex index.php
>
> AllowOverride All
>
> Order allow,deny
>
> Allow from all
>
> </Directory>
>
>
>
> <Directory /var/www/registry/auth/login>
>
> AuthType shibboleth
>
> ShibRequestSetting requireSession 1
>
> require valid-user
>
> </Directory>
>
>
>
> <Files *.sso>
>
> setHandler shib-handler
>
> </files>
>
> </VirtualHost>
>
>
>
> Can you help us? Do you have any ideia what could be the problem.
>
>
>
> Regards,
>
>
>
> Pedro Severino
>

Attachment: smime.p7s
Description: S/MIME cryptographic signature




Archive powered by MHonArc 2.6.16.

Top of Page