web server problems

[serengeor]

I'm using ubuntu 10.04 at the moment, and I have installed required things to have to host web server.

when I open up my page on local host I see this:

When I open up it on my real ip address it looks like this:


Uploaded with ImageShack.us

Code: Select all

#header{
	width:100%;
	height: 180px;
	background-image:url("./images/header.png");
}

What could be the problem?

[kazymjir]

Seems to be something with this file.
I checked http://62.80.252.115/images/ and everything works fine, without header.* files. (I am getting this message: "The image “http://62.80.252.115/images/header.gif” cannot be displayed, because it contains errors.").
Try to save them from image editing soft again and put in your server files.

[Eigen]

But if you use

background: #0000ff url("./images/header.png");

do you then see a blue background? In that case it can't find the image.

[serengeor]

But if you use

background: #0000ff url("./images/header.png");

do you then see a blue background? In that case it can't find the image.

Yes I do see blue background.

The image is ok, I think because when I access the site trough local host I can see the image, also I can see the image when the website is uploaded to free web hosting service.

EDIT:Tried different image, resized with gimp, still not working >:/

[kazymjir]

No, it finds image.
Look: http://62.80.252.115/images/header.png
But it containing errors:
"The image “http://62.80.252.115/images/header.png” cannot be displayed, because it contains errors.".

If it works fine at localhost and free webhosts, that must be something with your server software.
Are you using Apache? Which version?

[serengeor]

I know that it finds it, but it doesn't display.
I'm using Apache/2.2.14

EDIT: Even not edited picture doesn't display.

Okay so the size of the image is a problem i scaled my background image to 1024x180 and reduced the quality to 15% and now its 1.9kb and I can see it tough a 4kb picture is not displayed.
What could be the problem?

[kazymjir]

Ok, I tried to use wget and what i get:

Code: Select all

kazymjir@stallman2:~$ wget -d http://62.80.252.115/images/header.png
DEBUG output created by Wget 1.12 on linux-gnu.

--2010-12-08 11:03:41--  http://62.80.252.115/images/header.png
Connecting to 62.80.252.115:80... connected.
Created socket 3.
Releasing 0x0000000000720fc0 (new refcount 0).
Deleting unused 0x0000000000720fc0.

---request begin---
GET /images/header.png HTTP/1.0
User-Agent: Wget/1.12 (linux-gnu)
Accept: */*
Host: 62.80.252.115
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response...
---response begin---
---response end---
200 No headers, assuming HTTP/0.9      <<------------------------------[
Length: unspecified
Saving to: `header.png.1'

But on other files:

Code: Select all

kazymjir@stallman2:~$ wget -d http://62.80.252.115/images/grad.gif
DEBUG output created by Wget 1.12 on linux-gnu.

--2010-12-08 11:04:56--  http://62.80.252.115/images/grad.gif
Connecting to 62.80.252.115:80... connected.
Created socket 3.
Releasing 0x0000000001b66fc0 (new refcount 0).
Deleting unused 0x0000000001b66fc0.

---request begin---
GET /images/grad.gif HTTP/1.0
User-Agent: Wget/1.12 (linux-gnu)
Accept: */*
Host: 62.80.252.115
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 200 OK
Date: Wed, 08 Dec 2010 10:04:55 GMT
Server: Apache/2.2.14 (Ubuntu)
Last-Modified: Tue, 07 Dec 2010 17:29:50 GMT
ETag: "2ac2147-4f4-496d55a1e8bf2"
Accept-Ranges: bytes
Content-Length: 1268
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: image/gif

---response end---
200 OK           <<------------------------------[
Registered socket 3 for persistent reuse.
Length: 1268 (1.2K) [image/gif]
Saving to: `grad.gif.1'

This is very popular problem in Ubuntu, when smaller files working ok, but bigger not.

You need just to set this in your apache config:

Code: Select all

# EnableMMAP and EnableSendfile: On systems that support it,
# memory-mapping or the sendfile syscall is used to deliver
# files. This usually improves server performance, but must
# be turned off when serving from networked-mounted
# filesystems or if support for these functions is otherwise
# broken on your system.
#
EnableSendfile off 

Should work

[serengeor]

Yea!
Thanks

[randomMesh]

Are these SHA1 hashed passwords?

Code: Select all

8 December 2010<br />connected!<br />Array
(
    [0] => 3
    [1] => serengeor
    [2] => ccbb64c63b4020cb79990402f2a096761f523cb4
    [3] => serengeor@gmail.com
    [4] => male
    [5] => 0
    [6] => 2010-12-06 23:23:17
)
<br />Array
(
    [0] => 4
    [1] => MomDadLolWow
    [2] => 88d28ff59b031dbd906ca6d8f0e9535ae40c4ad5
    [3] => Maxjoe2007@gmail.comN
    [4] => male
    [5] => 0
    [6] => 2010-12-06 23:26:43
)
<br />Array
(
    [0] => 5
    [1] => serenge
    [2] => ccbb64c63b4020cb79990402f2a096761f523cb4
    [3] => serengeor@gmail.com1
    [4] => male
    [5] => 0
    [6] => 2010-12-06 23:33:35
)
<br />

"Exploits for the MD5 and SHA-1 algorithms have become known. You may wish to consider using one of the other encryption functions described in this section instead."

http://dev.mysql.com/doc/refman/5.1/en/ ... tions.html

[serengeor]

yes these are SHA1 hashed passwords, and these are for learning purpose only.

But there isn't any way to recover password from sha1 hash without brute force, or is there?

I'll look into that page when I'll be back to web creation.

[randomMesh]

But there isn't any way to recover password from sha1 hash without brute force, or is there?

http://www.schneier.com/blog/archives/2 ... roken.html

[serengeor]

Jordan is correct - 2^69 is still a large data space to search.
However, as Randell points out, this is a lot better than 2^80.
Assume you had 100,000 CPUs each capable of 4,000,000,000 tests per second.
That works out to 1,475,739 seconds to find a collision or about 17 days.
It is unlikely that such equipment exists, but it gives an idea of a possible worst case.
However, many digital signatures need to be secure much longer than 3 weeks.

huh