Welcome, Guest. Please login or register.
Did you miss your activation email?


Login with username, password and session length

Search

 
Advanced search

8043 Posts in 1856 Topics- by 2099 Members - Latest Member: roi
Pages: [1] 2   Go Down
Print
Author Topic: log in no longer working  (Read 737 times)
0 Members and 1 Guest are viewing this topic.
Oliver
New Member
*

Karma: 0
Offline Offline

Posts: 0

web designer


WWW
« on: June 27, 2004, 02:39:00 PM »

For some reason neither I nor any other user can log into the calendar anymore. I get the login screen, enter username and pw, then I get to select only "default calendar" no others, and if I select that one I'm just thrown back to the log in screen. Any idea why this happens? I urgently need to add some new items and make some changes to the calendar as soon as possible.

The calendar itself is still there and displays just fine, alas, I can't get into it and it shows wrong information now.

Thanks for any help!!!
The site is on an apache server, I use netcaptor (but also tried IE and others), I get no error message and the calendar worked fine for years. My webhost is also looking into this...

Thanks!

Oliver


Oliver

Logged
Oliver
New Member
*

Karma: 0
Offline Offline

Posts: 0

web designer


WWW
« Reply #1 on: June 27, 2004, 03:27:00 PM »

I also just ran the debug and get this result (keep in mind that everything worked just fine two weeks ago and that the calendar still displays just fine):
CalendarScript Debugger

There were problems detected with the files or directories needed by CalendarScript. These problems may be caused by one of the following:
"The file does not exist" problems are usually caused by the $BASE_DIR path being incorrect.
"No READ access" and "No WRITE access" problems are usually caused by forgetting to CHMOD the files or directories after transfer, or not giving the correct permissions in Windows.
"The file was not transferred in ASCII mode" problems are caused by not explicitly transferring files in ASCII mode in your FTP program. Some FTP programs make it appear like you're transferring in ASCII mode, when in fact you're in "Auto" mode or something similar, and this can cause problems.
The files with problems are listed below.

Problem File/Dir
•The file does not exist
/home/nineteen/public_html/cgi-bin/calendarscript/session/junk.txt
Once this problem is fixed, please re-run this debugger to check for any further errors!

------------------

Logged
Oliver
New Member
*

Karma: 0
Offline Offline

Posts: 0

web designer


WWW
« Reply #2 on: June 27, 2004, 03:32:00 PM »

I don't see an edit function on this forum, so I'll post this as yet an other message, sorry..

I just looked into the session directory, there's no file called junk, just files with numbers as name, such as 1011197140.txt for example.

Oliver

------------------

Logged
Oliver
New Member
*

Karma: 0
Offline Offline

Posts: 0

web designer


WWW
« Reply #3 on: June 27, 2004, 03:44:00 PM »

one last thing, I'm using the default calendar, not a different named one as I mentioned above. Sorry about that, I just got back from vacation in Italy, I was w/o sleep for over 24 hours when I found this problem yesterday....

Last post for now, I hope somebody can help me.

Thanks!

Oliver

------------------

Logged
DanO
Moderator
Full Member
*****

Karma: 13
Offline Offline

Posts: 230

Please don't PM me. Post in the open forum.


WWW
« Reply #4 on: June 27, 2004, 05:34:00 PM »

** I don't see an edit function on this forum **

Click the     button on the message you want to edit.

I'm afraid I don't know what is causing your problem besides maybe incorrect permissions. It is not unheard of for server maintenance to change permissions unexpectedly (or for host's support to deny any changes took place which may be responsible).  

Dan O.

[This message has been edited by DanO (edited June 27, 2004).]

Logged
Oliver
New Member
*

Karma: 0
Offline Offline

Posts: 0

web designer


WWW
« Reply #5 on: June 27, 2004, 06:05:00 PM »

duh, should have seen that edit button...

thanks for the info, I'll forward that to my host. There were other problems with the site that they're currently looking into, maybe I just have to change permissions back to what they have to be. If I find any other info and can't fix the thing I'll post again, and I'll also let you know if I was able to fix things with the above info!!

Thanks again!

Oliver

------------------

Logged
Oliver
New Member
*

Karma: 0
Offline Offline

Posts: 0

web designer


WWW
« Reply #6 on: June 28, 2004, 09:12:00 AM »

Hi DanO, my host is asking in which file or database the passwords are kept. For some reason the whole site got deleted (we're still trying to figure out what happened there) and they restored it from a server backup. But the calendar had started to act up about two weeks before that (just when I left for vacation...).

Admin screen comes up, but after log in and selecting the default calendar it just goes back to the log in.

I don't know perl and am not familiar with the database structure behind the calendar. My host said that i might have to re-crate some MySQL databases that might not have gotten restored with the backup. But since the calendar itself works and displays just fine, I'm not sure that's an issue.

I searched around here for similar problems and found different sollutions people used, I sent them all to my host. As for $base_dir, I just looked at my calendar_admin.pl file and here's what it says:

#!/usr/bin/perl
#
# CalendarScript
# Version: 3.1
#
# Copyright 2001 Scott
# http://www.CalendarScript.com/
#

BEGIN {
   # CHANGE THE LINE BELOW IF NECESSARY
   # Be sure to remove the # before $BASE_DIR, and change the path between the quotes
   #$BASE_DIR = "/...change.to.full.file.path.of.dir.../calendarscript/";
   
   # DO NOT CHANGE ANYTHING BELOW HERE!

Now, if I read that correctly, there's no base directory set? But how could that be, the calendar worked for a long time just fine. It has the same line in calendar.pl too. But the calendar itself displays just fine.. :-(


Any other ideas?

Thanks,

Oliver

------------------
edited 6-28 7:38am

[This message has been edited by Oliver (edited June 28, 2004).]

Logged
DanO
Moderator
Full Member
*****

Karma: 13
Offline Offline

Posts: 230

Please don't PM me. Post in the open forum.


WWW
« Reply #7 on: June 28, 2004, 12:52:00 PM »

** my host is asking in which file or database the passwords are kept. **

In the users.txt file in the /calendarscript directory.

** there's no base directory set? But how could that be **

Normally the BASE_DIR is derived from enviromental variables on the system it is running on. If those variables are not set on the particular server or you want the data files to reside in a directory other than the default (/calendarscript), then the $BASE_DIR variable must be set manually.

Dan O.

------------------

Logged
Oliver
New Member
*

Karma: 0
Offline Offline

Posts: 0

web designer


WWW
« Reply #8 on: June 28, 2004, 01:09:00 PM »

Thanks Dan.
I still can't figure out what is going on. I checked everything I can think of, but I still get the loop-de-loop around. I log in, it tells me I'm logged in and to select a calendar, I select the only one that's there and I'm back at the login.

Might a file be corrupted? Should I upload my local copy of the admin file (or maybe an other file?) Or do a new installation? If so, whould that overwrite my events and settings? Which files would I need to backup to make sure everything looks as it's supposed to later on.

I'm at a complete loss here, I don't understand why it suddenly won't work anymore. Unfortunately I don't know Perl so I can't really poke around. Nothing changed with the directories, and since the calendar itself displays just fine I'm sure that's not the issue.

I noticed that the files permissions.txt and users.txt are set to 644, everything else is set to 755 (777 is not allowed on my host). Only the session files in the sessions folder are also at 644. Should I change any of those? I tried with the two files I mention, but it did not seem to help.

I really need to get this up and running again, there's outdated information on the calendar.

Thanks for any additional ideas! I searched the forums here but found no applicable sollutions, though I might have overlooked something.

Oliver

------------------

Logged
DanO
Moderator
Full Member
*****

Karma: 13
Offline Offline

Posts: 230

Please don't PM me. Post in the open forum.


WWW
« Reply #9 on: June 28, 2004, 05:43:00 PM »

** I noticed that the files permissions.txt and users.txt are set to 644, ... Only the session files in the sessions folder are also at 644. **

Data files and their directories should usually be chmod to 666 (read and write permissions) or 766 depending on the server set up.

I don't know what else to suggest, sorry.

Dan O.


[This message has been edited by DanO (edited June 28, 2004).]

Logged
Oliver
New Member
*

Karma: 0
Offline Offline

Posts: 0

web designer


WWW
« Reply #10 on: June 28, 2004, 06:15:00 PM »

Hi Dan, neither option works.

You say 666 or 766, is that for ALL files under the calendar folder (including the calendar folder)? The instructions I printed when I installed this say 777 for everything and my host requires 755. Which worked just fine for a while...

Any idea what else could be wrong? I'd rather not have to install a different calendar, this one worked just fine for a while now. I'd be happy to give you url and log in info via e-mail if that might help, I don't want to post it here of course :-)

I'm still getting the loop around: sign in, select calendar, sign in, select calendar, .....

Are there some instructions on doing a new installation without deleting all the entered events? Or, which files would I have to backup and replace after a new install, to make sure all my events and calendar settings remain?

Maybe you know somebody else that might have an idea? There must be somebody that can figure this out? I'm at a loss, but I'm also not a perl person - sadly~~

Oliver

------------------


[This message has been edited by Oliver (edited June 28, 2004).]

[This message has been edited by Oliver (edited June 28, 2004).]

Logged
DanO
Moderator
Full Member
*****

Karma: 13
Offline Offline

Posts: 230

Please don't PM me. Post in the open forum.


WWW
« Reply #11 on: June 28, 2004, 08:03:00 PM »

** You say 666 or 766, is that for ALL files under the calendar folder **

Just the files and directories which get written to by the script.

** my host requires 755. Which worked just fine for a while... **

755 is usually just for scripts and their directories but depends on the way the server was set up.

** Are there some instructions on doing a new installation without deleting all the entered events? **

Not that I know of.

How about trying to install it from scratch but in a different directory? That way you can see if you can get it to work without loosing any of the original data?

Dan O.

------------------

Logged
Oliver
New Member
*

Karma: 0
Offline Offline

Posts: 0

web designer


WWW
« Reply #12 on: June 29, 2004, 09:58:00 AM »

Hi Dan, I'll look at those permissions again and try different settings. If that won't work I'll try the mentioned re-install.

My server requries such files to be set to 755, not 777 as the manual says. But that worked just fine so far.

How does the log in process work? I'd guess once I enter name and pw the program checks to make sure it's correct. I can log in (get the logged in message), but when I then select the default calendar I just get back to the log in screen. What proess(es) would run after the calendar selection? Maybe the calendar can't find the file or can't write to the sessions folder? Would that explain the loop back to the log in? I'm just trying to trace this step by step to find what the issue is.

Thanks for all the help!

Oliver

------------------

Logged
DanO
Moderator
Full Member
*****

Karma: 13
Offline Offline

Posts: 230

Please don't PM me. Post in the open forum.


WWW
« Reply #13 on: June 29, 2004, 12:57:00 PM »

** How does the log in process work? I'd guess once I enter name and pw the program checks to make sure it's correct. **

Correct, then it sets a cookie. If the cookies aren't set or the session can't be written, then the script doesn't know you're logged in and will likely ask you to (again).

Dan O.

------------------

Logged
Oliver
New Member
*

Karma: 0
Offline Offline

Posts: 0

web designer


WWW
« Reply #14 on: June 29, 2004, 03:31:00 PM »

Thanks for the info.
It seems that I can log in, as it tells me that I'm now logged in as Administrator. From the process, what's the next step? I select the default calendar, but once I click the button I'm back at the log in. What is the program looking for after I select the calendar? Can it be that it can't find the files? I'd guess that I'd see an error then instead of getting back into the login, but I don't know how the process is programmed.

Any addtl info would be great, and help me and the server admins to figure out what is going on.

Thanks!!

Oliver

------------------

Logged
Pages: [1] 2   Go Up
Print
Jump to: