Please post any comments or errors (better yet fix them in the wiki page itself).
Date: 19 Nov 2008 01:19
Number of posts: 21
RSS: New posts
There is a ticket for this issue, but attached patch doesn't work for me. I tried few things to get workaround, but unsuccessfully. I create a ticket for lighttpd in hope that someone will fix that.
# cd /usr/sbin/ # mv lighttpd lighttpd.org # ln -s /opt/sbin/lighttpd lighttpd # chown -R www-data:www-data /var/log/lighttpd # /etc/init.d/lighttpd.sh restart
the www-data user does not exist anymore! it is replace by jewab user and group. I could'nt find the /var/log/lighttpd directory (only /var/log/lighttpd.pid)
/etc/init.d/lighttpd.sh does not exist neither! (and I guess the script is suppose to be called S80lighttpd but could'nt find it anyway)
# cp /etc/lighttpd/lighttpd.conf /etc/lighttpd/lighttpd.conf.bak
lighttpd.conf is now located in /opt/etc/lighttpd.conf
I don't know why, but the only way to get lighttd running after changing the .conf was to install e2fsprogs!
To end, I couldn't manage to achieve what I wanted to do with webdav, and could'nt get ssl properly work…to be continued!
I have a bluering.
After having done the steps down to (but not including) "Enable encryption" I tried to restart lighttpd using:
I then get the following error when starting lighttpd:
/usr/sbin/lighttpd: can't resolve symbol 'gzopen64'
After having googled some about it I think I now know the reason: zlib (a lib that lighttpd depends on) normally does not contain gzopen64, but Ubuntu uses a modified version of zlib that does contain gzopen64. The developer who setup this lighttpd package was probably using Ubuntu (see this thread: http://forums.fedoraforum.org/showthread.php?t=228945).
So I located the zlib source for Ubuntu with version 1.2.5-1 (the version used in my optware)
I downloaded it and now want to compile and install it. I am very new on Linux, but thought that I could handle a single install. But zlib required all these software:
It feels like it is getting too complicated for someone like me.
Can anybody help me?
I had a problem with similar nature. I guess there are duplicated libs. you may refer to
Thanks for your reply!
(My previous reply to you seemed to have disappeared)
I did a search (using both grep and find) for duplicates of zlib (like you suggested) but found none. If there is a duplicate I do not know how to find it or fix it.
I have tried to create a normal forum thread about the issue instead to see if it can get some attention.
I will update the tutorial if I get the problem solved.
the basic steps are
then try to find all libraries used by lighttpd use find
can you post output from ldd step?
Thanks a lot! This feels like it will get me somewhere!!
ldd /usr/sbin/lighttpd libpcre.so.0 => /opt/lib/libpcre.so.0 (0x4000d000) libdl.so.0 => /lib/libdl.so.0 (0x40037000) libssl.so.0.9.8 => /opt/lib/libssl.so.0.9.8 (0x40041000) libcrypto.so.0.9.8 => /opt/lib/libcrypto.so.0.9.8 (0x40088000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x401ba000) libc.so.0 => /lib/libc.so.0 (0x401cb000) libstdc++.so.6 => /lib/libstdc++.so.6 (0x40225000) libm.so.0 => /lib/libm.so.0 (0x402b4000) ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x40000000)
Ok. Lets look for the libraries:
find / -name "libpcre.so.0" /opt/lib/libpcre.so.0 find / -name "libdl.so.0" /lib/libdl.so.0 find / -name "libssl.so.0.9.8" /opt/lib/libssl.so.0.9.8 find / -name "libcrypto.so.0.9.8" /opt/lib/libcrypto.so.0.9.8 find / -name "libgcc_s.so.1" /lib/libgcc_s.so.1 find / -name "libc.so.0" /lib/libc.so.0 find / -name "libstdc++.so.6" /lib/libstdc++.so.6 /opt/lib/libstdc++.so.6 find / -name "libm.so.0" /lib/libm.so.0 find / -name "ld-uClibc.so.0" /lib/ld-uClibc.so.0
Ok. All the libs, except one, only exists in one copy with the correct link from lighttpd. But I've got 2 matches on libstdc++.so.6. Let's have a look:
ls -l /lib/libstdc++.so.6 lrwxrwxrwx 1 root root 18 Jan 1 1970 /lib/libstdc++.so.6 -> libstdc++.so.6.0.2 ls -l /lib/libstdc++.so.6.0.2 -rwxr-xr-x 1 root root 534272 Jan 18 2008 /lib/libstdc++.so.6.0.2 ls -l /opt/lib/libstdc++.so.6 lrwxrwxrwx 1 root root 18 Jan 17 13:46 /opt/lib/libstdc++.so.6 -> libstdc++.so.6.0.2 ls -l /opt/lib/libstdc++.so.6.0.2 -rw-r--r-- 1 root root 534312 Jun 21 2010 /opt/lib/libstdc++.so.6.0.2
At least they have the same version number, but the opt version is not executable. How could I try to link lighttpd to the opt version of the lib instead? Do I need to do a chmod to 755 for the opt lib then?
Thanks again for trying to help!
ls -l /lib/libstdc++.so.6
lrwxrwxrwx 1 root root 18 Jan 1 1970 /lib/libstdc++.so.6 -> libstdc++.so.6.0.2
ls -l /lib/libstdc++.so.6.0.2
-rwxr-xr-x 1 root root 534272 Jan 18 2008 /lib/libstdc++.so.6.0.2
ls -l /opt/lib/libstdc++.so.6
lrwxrwxrwx 1 root root 18 Jan 17 13:46 /opt/lib/libstdc++.so.6 -> libstdc++.so.6.0.2
ls -l /opt/lib/libstdc++.so.6.0.2
-rw-rr 1 root root 534312 Jun 21 2010 /opt/lib/libstdc++.so.6.0.2
you may try this
backup libstdc++.so.6.0.2 and link to default one
mv libstdc++.so.6.0.2 libstdc++.so.6.0.2.bak
ln -s /lib/libstdc++.so.6.0.2 ./libstdc++.so.6.0.2
as a result your
/opt/lib/libstdc++.so.6 is linked to /lib/libstdc++.so.6.0.2
you can reverse back if this is not working and try other options
I tried your idea to create a link, but the other way around. Lighttpd currently points to /lib/libstdc++.so.6, so I made a backup of that file and created a symbolic link to /opt/lib/libstdc++.so.6 instead. It did not work. Same error.
But, like I just said (in a post that appearantly is displayed below this): The problem only appears when trying to use mod_webdav.
So now having learned about the ldd command, I tried to use it on mod_webdav:
ldd /opt/lib/lighttpd/mod_webdav.so libxml2.so.2 => /opt/lib/libxml2.so.2 (0x00000000) libsqlite3.so.0 => /opt/lib/libsqlite3.so.0 (0x00000000) libuuid.so.1 => /opt/lib/libuuid.so.1 (0x00000000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00000000) libc.so.0 => /lib/libc.so.0 (0x00000000) libdl.so.0 => /lib/libdl.so.0 (0x00000000) libz.so.1 => /opt/lib/libz.so.1 (0x00000000) libiconv.so.2 => /opt/lib/libiconv.so.2 (0x00000000) libm.so.0 => /lib/libm.so.0 (0x00000000) libpthread.so.0 => /lib/libpthread.so.0 (0x00000000) libc.so.6 => not found (0x00000000) /lib/ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x00000000)
This was very interesteing, since I have a missing lib here: libc.so.6.
I did a find on it and found none, what I did find whas this:
lrwxrwxrwx 1 root root 19 Jan 1 1970 /lib/libc.so.0 -> libuClibc-0.9.28.so
So it seems like optware expects me to have libc in a much newer version than I have.
I tried to do a normal firmware upgrade, but it reported "There is no new firmware available". I have firmware version 02.00.19.
Do you have a bluering.? Do you think you could upload the file to the webdav tutorial (http://mybookworld.wikidot.com/webdav) (Files at the bottom of the page)? After having searching the forums about this it seems like libc.so.6 is only a pointer to glibc so something like that. Could you check if your libc.so.6 points to another file and upload this instead in that case?
Thanks a lot for your help!!!
I just remembered that I forgot to add a significant info about my problem:
It only appears once I have added "mod_webdav" to server.modules in /etc/lighttpd/lighttpd.conf.
If I do not add this to the lighttpd config file, lighttpd restarts without errors and works fine.
So I guess the error comes from something in mod_webdav.
Sorry for not remembering to say this before.
I have a bluering, but I keep it as simple as possible, mainly using ssh, rsync, nfs etc. here is the links on libc in my system
[NAS 07:38:58|~] ll /lib/libc* /lib/libuC* /opt/lib/libc.so.0
lrwxrwxrwx 1 root root 24 Jul 22 2009 /opt/lib/libc.so.0 -> /lib/libuClibc-0.9.28.so
-rwxr-xr-x 1 root root 11052 Jan 18 2008 /lib/libcrypt-0.9.28.so
-rwxr-xr-x 1 root root 317756 Jan 18 2008 /lib/libuClibc-0.9.28.so
lrwxrwxrwx 1 root root 19 Jan 1 1970 /lib/libc.so.0 -> libuClibc-0.9.28.so
lrwxrwxrwx 1 root root 18 Jan 1 1970 /lib/libcrypt.so.0 -> libcrypt-0.9.28.so
YES, I upload /lib/libuClibc-0.9.28.so to that location
But you have the same old version as I have. I read another thread about trying to link libc.so.6 to another version (for Transmission). They did not get any errros, but it did not work anyway (even worse).
In yet another thread I read about someone asking for libc.so.6 over email. I will try to contact them. I will post any progress.
This problem is due to lighttpd binary loading /lib/libz.so instead of /opt/lib/libz.so. The only way to solve it is to enable LDSO_RUNPATH support in uclibc. Simply install ldso-runpath-enabled-firmware to solve this issue.
Thanks a lot!
I finally realized what the problem was (that lighttpd did not use the opt version of libz, like you also pointed out), but when I tried to remove the /lib/ version or repoint to opt my ssh connection stopped working. Very frustrating!
After your post I started with the howto for ldso-runpath-enabled-firmware, but I am am stuck with not being able to unmount /shares/internal no matter how I try. I will report back if the ldso-runpath-enabled-firmware solved the problem once I get through the howto.
Yep, it worked!
I did not get the error after installing the ldso-runpath-enabled-firmware. Thanks!!
I now have webdav working with encryption, but still some problems. New Post :-).
You're welcome :)
New Post :-)
Ok, better post in the firmware support thread. I already saw your update about lighttp.conf. It appears there're some errors in the upgrade scripts, which are supposed to preserve user lighttpd.conf. I'll look at it now, but I can't test it, since I run armel Debian on my box.
UPD: the upgrade scripts look fine. Added
rm -rf /var/upgrade/bak mkdir /var/upgrade/bak
just in case the previous upgrade backups get in the way. Released it as v3.2.1
P.S. sorry for the off-topic
UPD2: ah, I see, those problem are webdav-related - not firmware-related :) then it's the right place to post. Sorry I can't help, though, since I don't use webdav
I am missing the lib "libc.so.6". I think it is located in your /lib/ folder (not in opt). The file itself is probably a link to the real lib (I need the lib, not the link :-)
Could someone either email me the file (mailto:firstname.lastname@example.org) or upload it to the Webdav tutorial (just press "Files" at the bottom http://mybookworld.wikidot.com/webdav).
It is required for Webdav, but I do not have it.
Thanks for your help!
I have updated the tutorial as far as I have come.
This now works:
- Enctypted read access to the webdav drive using a web browser
- Unencrypted read access to the webdav drive using Windows explorer
- Saving files <~70 Kb from Notepad++
This does not work:
- Encrypted access to the webdav drive from Windows explorer
- Uploading files using Windows explorer
- Saving files >~70 Kb from Notepad++
1. Encrypted access to the webdav drive from Windows explorer
I can access the webdav drive using \\192.168.0.100\dav. But when I try access/map the drive using https://192.168.0.100/dav or \\192.168.100@SSL\dav I get an error saying that the folder is not correct (translated from swedish).
Is this a Windows Vista problem? Any ideas?
2. Uploading files using Windows explorer
When I try to upload a file to the webdav drive using Windows explorer I get the following error: 0x80070021.
This seems to be because of that the sqlite db does not work correctly which makes locks and props not working as mentioned in the webdav tutorial. Any ideas why?
The sqlite db file at least gets created:
# ls -l /opt/var/run/lighttpd/lighttpd.webdav_lock.db -rw-r--r-- 1 www-data www-data 5120 Feb 17 10:25 /opt/var/run/lighttpd/lighttpd.webdav_lock.db
And the error.log does not mention any problems:
# tail /opt/var/log/lighttpd/error.log 2011-02-17 10:50:42: (log.c.166) server started
3. Saving files >~70 Kb from Notepad++
I have no idea why this is the case. Googled around and found some threads with similar problems, but with webdav on IIS: (http://forums.iis.net/p/1153941/1888235.aspx).
The setting mentioned there (maxAllowedContentLength) does not seem to exist in lighttpd. I tried setting the setting server.max-request-size = 2097152, (2 GB) which should be the default setting, but the problem remained.
At least something is working :-)