열린 작업방

#!/bin/bash grep -v ^# squid.conf | grep -v ^$ > real.conf

error_directory /usr/share/squid/errors/Korean # 최대저장 용량 200000 (=200G) cache_dir ufs /data/squid 200000 16 256 # 서비스할 파일의 최대 크기 20G maximum_object_size 20470 MB acl localhost src 211.53.35.0/24 #=========================================== emulate_httpd_log on maximum_object_size_in_memory 10240 KB # recommanded value = RAM / 3, 1024 MB -> 2560 MB cache_mem 2560 MB #=============================..

I mentioned YSlow in my last post in reference to speeding up the sites you develop. Depending on your skill level, however, you may or may not be aware of ways in which you can implement a lot of those changes. Things like ETags and expire headers can be a little esoteric to people who don’t deal with that kind of stuff every day, so I thought I’d put together a few links where you can learn mo..

3.1. 지연풀 특징을 갖는 스퀴드 설치하기 앞에 언급했듯이 스퀴드는 다운로드 대역폭을 제어할 수 있도록 하는 지연풀이라는 특징을 갖고 있다. 그러나 불행히도 대부분의 배포판에서 스퀴드는 이 특징없이 설치된다. 그래서 스퀴드가 이미 설치되어 있다면 이를 설치제거한 후 밑에 설명된 방식으로 지연풀 기능이 작동하도록 다시 설치해야 한다. 스퀴드 프록시에서 최대 성능을 얻기 위해서는 /cache/ 라는 캐시 전용 파티션을 생성하는 것이 가장 좋은데 그 크기는 필요에 따라 대략 300 MB 정도여야 한다. 독립된 파티션 생성 방법을 모른다면 주 파티션에 /cache/ 디렉토리를 생성할 수 있지만 스퀴드 성능은 약간 저하될 수 있다. 안전한 'squid' 사용자를 추가한다: # useradd -d /cache/ ..

사용목적 squid을 accelerator mode로 사용하는 이유는 웹서버의 부하을 덜어주기 위함이다.자주 접근되는 웹서버의 내용을 squid의 캐쉬에 저장시켜 클라이 언트로부터 요청이 있을시 웹서버에 요청하지 않고 캐쉬에서 바로 보내 줌으로 써 서버의 이용률을 높일 수 있게 되는것이다.클라이언트로 부터 오는 요청중 캐쉬에 저장될 수 없는 cgi같은 내용만 웹서버로 직접 전달시켜줄 뿐 나머지 캐쉬로 저장해두 무방한 html이나 gif,jpg같은 내용은 캐쉬에서 바로 클라이 언트로 응답을 해줌으로서 속도을 증가시켜 주는 역할을 한다. squid는 클라이언트와 웹서버의 중간자 역할을 수행한다고 생각하면 이해하기 가 수월할 것이다.클라이언트의 요청을 squid가 받아서 squid의 cache에 보관되 어 있..

3M File dd bs=1024K if=/dev/zero of=monitor3.file count=3 10M dd bs=1024K if=/dev/zero of=monitor10.file count=10 7G dd if=/dev/zero of=update-7G.zip bs=1M count=716813Gdd if=/dev/zero of=update-13G.zip bs=1M count=13312

얼마 전 담당했던 서버의 보안 취약점 사례. 이 취약점은 의외로 자주 발견되는 취약점이기에, 이렇게 포스트로 적는다. 보통 경험이 짧은 서버 개발자가 일으키는 가장 초보적인 취약점이기 때문. 서버 개발 경험이 많은 사람은 이미 알만한 내용이므로 굳이 볼 필요는 없다. 이 서버는 어쩌다 한번씩 마비되는 문제를 갖고 있었다. 버그를 찾아봤지만, 버그를 못찾겠단다. 공격으로 판단할만한 과다 트래픽도 없었으며, 그만한 CPU 점유율도 발생하지 않았단다. 예외 발생도 없고 그냥 마비된단다. 헌데 항상 마비되는 시점은 동접이 많고 서비스가 활발히 이루어지는 시점이라, 패킷 덤핑을 통해 분석하려니 분량이 너무 많아 대책이 없는 상황. 사실 패킷 덤핑 분석까지 갔다면 거의 OTL orz ___ 상황이라는 의미. 이유는..