Getting Error when making changes to page
Brought to you by:
donmurray,
jmcwhirter
Menu
▾
▴
#3 Getting Error when making changes to page
Regardless of if I'm logged onto an admin account or a user account - when I make a change to a page I get the following error: "You do not have permission to access this page". Don't know what version of RAMADDA... downloaded it Sept 2010 if that helps. Also - we initially set it up but then I forgot admin login. In our efforts to follow instructions to re-establish admin capability we may have corrupted something? Please advise. Thanks
Hi Tara,
Resetting your admin password from the command line shouldn't have an effect on anything.
If you are logged in as admin you should be able to do anything. Can you upload new files?
I am in the middle of releasing a new 1.3beta version this weekend. Why don't you install the new
version next week and then try it.
-Jeff
Prior to resetting the password in the XML (as per FAQ instructions), we had blown away the directory created by exploding the .war. After doing so - when we restarted tomcat and tried to restart the repository, it would create the directory one level up from the .war rather than making the directory at the same level and exploding the contents into it. So our engineer manually made the directory and manually unpacked the .war. We recovered our repository web-interface and admin privileges but now whenever I make a change to any setting, try to add new content, try to upload a new file, anything, it bounces me out and says "You do not have permission to access this page"... however it makes the change. If I'm not an admin - it's even worse as I can't upload new files... it just bounces me out after I click New -> File and give me the error.
We will look for the new release on Monday or maybe blow the old one away completely and re-install.
I don't know what could be going on but I'd first try to figure out why tomcat was behaving oddly.
-Jeff
I downloaded whatever was available on Monday afternoon. My engineer removed the .war, removed the subdirectory, removed the compiled JSPs, and restarted tomcat and we're still having the problem. The engineer wants me to let you know we're "we are configured to use the derby database. Our problem might just be a matter of clearing the information in that database." How would we do that... or at a more extreme level - how do you completely uninstall, wipe the slate clean, and start over? Thanks...
I've just made a new 1.3b release:
https://sourceforge.net/projects/ramadda/files/
Go ahead and try to reinstall the .war. If you see that access error again look at the stderr output from ramadda (under tomcat it should be in catalina.out). There is more better logging about why there is a problem.
About nuking your existing install - there might be an admin property that got set that is screwing things up but you shouldn't have to delete everything. If you are running with derby than everything is stored in the ramadda home directory:
<ramadda process home dir>/.ramadda
-Jeff
Hi Tara-
This is Don. I vaguely remember having a similar problem when I moved some files around. Check in the admin screen to make sure the list of viewable file systems includes all the directories you are trying to view. If that's not the issue, then I'm not sure what's going on.
Don
I'm still experiencing the same problem and we need to have this repository up and running for HEPEX as soon as possible... their workshop is early June. From Paul - our software engineer
Regarding the RAMADDA repository, I stopped tomcat, removed all compiled JSPs, removed the webapps folder, redeployed it
from the war file, and restarted tomcat. That's about as clean a redeployment as possible. If the problem persists,
it's pretty clearly a database issue. The email that you forwarded me mentions a .ramadda file. I'm not
able to find this file on web server. Also, I see this in the log file:
DatabaseManager.init
DatabaseManager.doMakeDataSource connection url:jdbc:derby:repository;create=true user name:null
DatabaseManager.init done
Repository.initSchema: loading schema
Repository.initSchema: done loading schema
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in
[jar:file:/opt/apache-tomcat-6.0.29/webapps/repository/WEB-INF/lib/repositorylib.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/opt/apache-tomcat-6.0.29/webapps/repository/WEB-INF/lib/repositorytds.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
RAMADDA started
UserManager: allowed ip addresses: []
ERROR:To run the IdvOutputHandler a graphics environment is needed
java.lang.IllegalArgumentException: This application needs Java 3D 1.2 or higher to run.<br>Please see the User's Guide
for more information.
at ucar.unidata.idv.IntegratedDataViewer.checkSystem(IntegratedDataViewer.java:398)
at ucar.unidata.idv.IntegratedDataViewer.<init>(IntegratedDataViewer.java:285)
at ucar.unidata.idv.IdvServer$MyIdv.<init>(IdvServer.java:133)
at ucar.unidata.idv.IdvServer.<init>(IdvServer.java:57)
at ucar.unidata.repository.idv.IdvOutputHandler.checkIdv(IdvOutputHandler.java:534)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at ucar.unidata.util.Misc$2.run(Misc.java:1062)
at ucar.unidata.util.Misc$3.run(Misc.java:1090)
Tara - are you running with the latest RAMADDA release? That has more better logging when there is the error you are encountering. If you still get the error there should be messages in catalina.out that look like:
Access error: user=" ...
... ok2 = ...
etc.
If you get this can you send me them?
As to the log warnings - those are OK and shouldn't be causing a problem.
The .ramadda directory is in the home dir of the process that is running ramadda (or you can also specify it explicitly when running).
If you don't care about the content that is currently in your ramadda server you can just blow away the .ramadda directory and start fresh.
-Jeff
This last re-install was with 1.3. I didn't look in the log files but will try to find time to do so. Honestly however, I don't care about the content on my server right now. It will take me 1 hour to redo everything. I would like to blow it away and redo it but every time we then we've what we think is nuking it the old repository is still there. My question to you is HOW do you nuke it and start from scratch... I can't find those instructions anywhere. Thanks!
Tara-
To start fresh just remove the ramadda home directory and restart ramadda (assuming you are running with the built in derby database).
The default location of the ramadda home directory is in:
<tomcat process home directory>/.ramadda
-Jeff
We are using derby. I'm 99.95% positive we've tried to remove whatever pieces of ramadda we can and being we can't find .ramadda - it's tough to remove it. Can I have Paul contact you directly? Maybe even via phone to talk through this... Right now it feels like we have a haunted server that refuses to die :)
RE: ramadda home directory - Paul did a "find" on .ramadda in lots of places as well as directly looking in as many obvious and potential hiding places he could think of on tomcat... he's not a novice to tomcat so I'm confident he expended some reasonable resources to find it... no go. So I think a direct consult would be the most effective approach to starting over. Thanks...
Tara -
Maybe you configured your tomcat startup to point to a different directory?
When RAMADDA starts up it prints out where its home directory is. Something like:
RAMADDA: home directory: /Users/jeffmc/.ramadda
You should grep through your tomcat log file (catalina.out) for that. Or in a separate window do:
tail -f catalina.out
and then restart your tomcat server.
-Jeff
Tara,
I just realized that I misspoke about the location of the ramadda home dir. Older versions of ramadda used <tomcat process home>/.unidata/repository as the home dir.
So, if you delete that then ramadda willl start fresh and will use:
<tomcat process home>/.ramadda
Sorry about misleading you. If there is anything else I can do to (actually) help you please feel free to ask.
-Jeff
We found home>/.unidata/repository and moved it out of the way. We restarted everything and I now have a clean repository but am still seeing one flavor of the behavior. Anytime I'm logged in as an admin, I am logged out whenever I add folder, file, or entry. I haven't even gotten to trying to login as a regular user and add a file or content where allowed. Sounds like we still have something wrong but unsure where to go. Can I have my engineer or sys admin contact you to pick it up from here. I think I'm getting in the way by being the middle-person.
Hi Tara,
Yes,. please feel free to have your folks contact me directly.
Instead of going through SourceForge just send me mail:
jeff.mcwhirter@gmail.com
-Jeff
Great - thanks - will do.
You can close this ticket. We finally diagnosed that we were having the problem when hitting the repository through the external web address but not through the internal address. We are using a proxy to redirect to the web server the repository sits on... setting the ProxyPassReverseCookiePath in the apache config on our primary web server solved the problem.