aMule Forum
English => en_Bugs => Topic started by: aldebaran on October 12, 2005, 03:38:37 PM
-
1) formatted my debian linux harddisk
2) compiled and installed wxGTK 2.6.2 without errors
3) compiled and installed aMule cvs20/10/05 (amule + amuled + amuleweb + amulecmd) without errors
4) executed 'make check' 5/5 tests passed
5) lounched amued + amuleweb all fine
6) in amuleweb pannel I found some errors (though I doubt whether they are from web interface or the daemon)
a) a part from server list (which is displayed correctly) all other tabs are displayed as "virgin". I mean as the first time you run amule: without any customisation.
in other words: Statistics tab shows as follows:
"shared files
Number of Shared Files: 59
Dimensione totale file condivisi: 26,01 GB
Dimensione media file: 451,35 MB"
but shared files tab shows like in the attached snapshot
-
Is there something webserver does display ?! Or you mean that it displays pages, but they are empty ?
-
please read below
-
displays the templates but does not display at all the custumed pages
Make us a favor: take your time to state (and spell) your question(s). Nobody is telepath here - please provide extensive explanation of:
1. What you have done
2. What you expected to happen
3. What has actually happen and why do you thing this is wrong.
-
Or take a screenshot that will turn the lights on in our heads.
-
As well when I do a search (for example word "linux") and press SEARCH button the frame window which should display the "refetch" link (the frame under the the upper toolbar) vanishes! No downloads are possible throgh this way.
As well after being connecte to server (due to my network no way to get high id) and Kadelmia (ok) no uploads are shown (no one actually requests any file, where with last stable amule release upload bandiwth was fulfilled just a few hours before I upgraded) .
Pasting an ed2k link makes amule download start, but this is how download tab in webserver shows as follow (no single item displayed - Show Queue button never worked (actually even in previous releases))
This is what I mean by saying that no customed page is displayed.
The problem occured in 12oct cvs (maybe before, I don't know) and is still present in todays cvs.
Hope I explained better the problem this time! :]
-
Got it. Happens to me once too.
Please try to run amuleweb manually with --php and report if problem persist.
-
with php it occures another problem!! :(
now with php template login page is displayed (also with beautiful php girl) but after logging in it only refreshes.
Cookies are enabled (SESSID cookie shows in cookies list)
Location of php-default template checked
also remote.conf file checked for correct template
also tried sending amuleweb template name with -t argument
still another problem :(
-
This has been reported once, but I could never reporoduce it. Please ensure that remote.conf contain valid password hash (it must be same as in amule.conf).
If your password hash is ok, but you still can't login, please run amuleweb without -q switch and post here output from terminal window.
-
lfroen,
it should be a php related problem since when I switch to old standard profile webserver grants me access again.
however I checked password ashes and resetted (deleted) both amule.conf and remote.conf
now these field are in amule.conf while remote.conf is empty (when I fill it with password=my_hash nothing changes):
AcceptExternalConnections=1
ECAddress=127.0.0.1
ECPort=4712
ECPassword=e9a23cbc455*
ShowProgressBar=1
ShowPercent=0
UseSrcSeeds=0
UseSecIdent=0
IpFilterOn=0
[WebServer]
Enabled=0
Password=e9a23cbc455*
PasswordLow=
Port=10970
UseGzip=0
UseLowRightsUser=0
PageRefreshTime=120
shell output is:
aMuleweb$
WSThread: Thread started
WSThread: created service
WSThread: created socket listening on :10970
WCThread: Started a new WCThread
No session opened - requesting login
Session created - requesting login
Warning: session is not logged in but request have no password
Processing request: login.html
WCThread: exited [WebSocket closed]
WCThread: Started a new WCThread
WCThread: exited [WebSocket closed]
WCThread: Started a new WCThread
Session ok
Checking password
Password bad
I wonder where webserver tries finding the password hash...
-
Session ok
Checking password
Password bad
That explains login failure. amuleweb (when run standalone) takes hash from remote.conf. Check is very simple: run amuleweb with --php option and without. If you you can login in one, but can not in another - that clearly indicate php failure. Remember to turn off "Automatic webserver start" in preferences before checking.
Your config files (both amule.conf and remote.conf) should contain something like this:
[Webserver]
Port=4711
UseGzip=0
AllowGuest=0
AdminPassword=e10adc3949ba59abbe56e057f20f883e
GuestPassword=d0970714757783e6cf17b26fb8e2298f
-
OK 8)
Things are getting better :D
Listen lfroen, amule / amuled creates config files with Password and PasswordLow values, while amuleweb php understands only AdminPassword and GuestPassword ones! That's why it didn't recognise the password! ;)
Also, in php mode shared files are displayed correctly,
while
Kad tab does not display anything (seems not working at all the button)
statistics tab only displays graphs (not textual statistics)
where is uploading clients list?
Thanks for your support and great work!
PS: it showed this error, I have no idea of what it means, but I think you do "PHP Error: Argument of 'foreach' must be array"
bye
-
Kad tab does not display anything (seems not working at all the button)
Kad page is actually not implemented yet, since I'm still considering what it should contain.
statistics tab only displays graphs (not textual statistics)
where is uploading clients list?
You seems have outdated template. I have fixed/implemented it 1-2 days ago.
Listen lfroen, amule / amuled creates config files with Password and PasswordLow
This appears to be correct. I have no idea who and why wrote it this way. But it looks like I will have to fix it somehow.
-
amule / amuled creates config files with Password and PasswordLow values, while amuleweb php understands only AdminPassword and GuestPassword ones! That's why it didn't recognise the password!
Easiest way to create a valid and working remote.conf:[list=1]
- Run amule, and set up webserver preferences in Preferences->Remote Controls
- run: amuleweb --create-config-from=amule.conf
- run amuleweb, and enjoy
[/list=1]
If wiki wasn't on maintenance mode, there is a page describing remote.conf contents.
The above instructions are also in amuleweb's man page.
-
Easiest way to create a valid and working remote.conf:
1. Run amule, and set up webserver preferences in Preferences->Remote Controls
2. run: amuleweb --create-config-from=amule.conf
3. run amuleweb, and enjoy
I think easiest way would skip step (2), i.e. pressing OK button should update content of remote.conf. The way it work now is one of most confusing things I ever saw. We have dedicated config file for remote tools, called remote.conf - lets be consistent and use only this one. Even if you have switch that let you choose another config file, wtf keys have different names there ?!
--create-config-from - this is first thing that I will drop (together with moving it's code to relevant part of Preferences.cpp).
-
wtf keys have different names there ?!
When we have an option to decide what keys we want to use, I believe they should be clean and self-explanatory.
amule.conf is a big mess as it is now. If you first saw "PasswordLow", what would you think it is for?
Unfortunately we can't expect to clean up amule.conf, because
1) backwards compatibility
2) eMule compatibility
Still this doesn't mean that we have to clone this mess on a new config file.
We have dedicated config file for remote tools, called remote.conf - lets be consistent and use only this one.
People may want to access amule core on more than one computer from the same computer (not necessarily at the same time), so we have to provide means to use any file as a config file. "remote.conf" is just the default.
I think easiest way would skip step (2), i.e. pressing OK button should update content of remote.conf.
I don't agree. Why should an application (over)write the configuration file of another app?
-
People may want to access amule core on more than one computer from the same computer
May I ask from what planet are you writing this ?! I may imagine scenario when I access my mule from different locations. But I can't even thing about opposite: having 2 mules at home. Please, don't waste your time explaining me that it's possible from technical point of view. Most chances it is and it doesn't matter - 1% of users with such demands will find the way, but other 99% (me including) want things to work on first attempt.
I don't agree. Why should an application (over)write the configuration file of another app?
I'll tell you "why". Because this would eliminate countless questions in forum "I have changed password, but can not login". It confuses users - so this must be bad. And btw, this is not "another app" - :)
-
Originally posted by lfroen
People may want to access amule core on more than one computer from the same computer
May I ask from what planet are you writing this ?! I may imagine scenario when I access my mule from different locations. But I can't even thing about opposite: having 2 mules at home. Please, don't waste your time explaining me that it's possible from technical point of view. Most chances it is and it doesn't matter - 1% of users with such demands will find the way, but other 99% (me including) want things to work on first attempt.
Just a simple case: One may have a mule(rabbit) running home an at the school/company/whatever. He'll most likely want to connect to the *other* mule, not the local, so the local shouldn't overwrite remote.conf. (Unless this man is masochist enough to always type the config file name on command line or wise enough to create a shell script (Oh, no!! Shell scripts are evil instantiations from Hell!!!!) to work it around.)
having 2 mules at home.
And, ehm, I never said "at home".
-
Just a simple case: One may have
That's exactly why I asked not to waste your time. Yes, you right, "one may have blah blah", and this is about 1% of amule usage. Make most common case use work smoothly, and then worry about corner-case scenarios.