DevNote - Linux

[윈도우서버] 최대 동접자수를 늘리기 위한 윈도우 서버 설정 윈도우에서 VMware로 다수의 리눅스 서버를 구동하고 있는 환경에서는 유입 트래픽이 윈도우를 거쳐 VMware로 유입되므로 윈도우 자체에서 동접자를 수용할 수 있어야 한다. 윈도우에서 최대 동접자를 늘리기 위한 레지스트리 설정 방법을 안내한다. 설정후 반드시 재부팅이 필요하다. regedit [윈도우 - 시작 - regedit] 로 레지스트리 편집기를 실행한다. 화면과 같이 두개의 옵션 값을 수정 혹은 추가한다. (아래 두 레지스트리가 없는 경우 추가한다.) MaxUserPort 통신 소켓(포트)의 최대 개수를 설정한다. 기본 값은 5,000 이다. 32비트 (REG_DWORD) / 최소 5,000 ~ 최대 65,534 / 기본값 5,000 TcpTimedWaitDelay TCP가 통신 소켓 연결을 해제하고 재사용 하기까지 기다려야 하는 시간을 설정한다. 기본 값은 240(초/4분) 이다. 32비트 (REG_DWORD) / 최소 30 ~ 최대 300 / 기본값 240

[nginx] ip로 접속하지 못하도록 설정 아이피로 접속하는 경우 444에서가 노출되도록 하는 방법. ip주소 접근 차단 vi로 default.conf를 연다. (기본 virtualhosts 설정) vi /etc/nginx/conf.d/default.conf default.conf 파일 최상단에 아래와 같이 추가한다. # ip 접근을 막기 위한 설정(http) server { listen 80 default_server; server_name _; return 444; } # ip 접근을 막기 위한 설정(https) server { listen 443 ssl default_server; server_name _; ssl_certificate /etc/letsencrypt/live/본인의 ssl경로/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/본인의 ssl경로/privkey.pem; return 444; } https 설정에서 ssl 인증서 경로는 기존에 virtualhost 를 위해 생성해둔 아무 인증서를 연결해준다. # systemctl restart nginx nginx를 재부팅. 아이피주소로 접속한 경우 위와 같이 444 에러가 리턴되는 것을 확인할 수 있다.

홈서버 구축기 / 보안을 염두한 홈서버 네트워크 구성 이사를 계획하게 되면서 새로운 집에서 홈서버 네트워크 구축을 해보자 맘을 먹었고 이사한지 한달도 채 되지 않아 IDC에서 운영중이던 서버를 반출하고 홈서버를 구축했습니다. 몇년전에도 홈서버를 구축했던 적이 있는데, 애매한 장비들로 구축하는 바람에 어설프게 끝나고 말았던 경험이 있습니다. 다시는 IDC 입주를 하지 않겠다는 굳은 각오로 홈서버 네트워크를 구축하게 되었으며, 고생 끝에 완성된 저만의 홈서버 네트워크를 기록으로 남겨 봅니다. (위에 얹어져 있는 1U는 소음 때문에 반나절만에 적출당한 서버입니다. -> 데스크탑으로 대체 되었습니다.) 1 홈서버 구축을 결심하게 된 이유 첫째, IDC 비용이 부담으로 다가왔습니다. 네임서버 2대, 웹서버 1대, 스토리지 서버 1대를 운영 중이었는데, 최근 이사를 하면서 큰 지출을 하게 되니 매달 지출되는 서버 비용이 아깝다 느껴졌습니다. 네임서버 2대를 AWS Route53으로 전환하고, 스토리지 서버를 시놀로지 나스로, 1U 웹서버를 데스크탑으로 타협하여 IDC 비용을 줄여보자는 계산이었습니다. 무엇보다 우리 집은 같은 방이라도 랜포트별로 개별 아이피가 들어오기 때문에 가성비 좋은 홈서버 구축이 가능한 상황이었습니다. (랜포트 마다 아이피가 다른건 처음이라 놀라웠습니다. 신축 아파트는 다 그런가요..?) 둘째, 서버를 소비하는 느낌이 싫었습니다. 제가 운영하는 웹사이트는 손수 디자인하고, 개발하여 제작하는 반면, 서버는 비싸게 구입하게 되지만, IDC로 직행하여 수명을 다할 때 쯤 되어서야 제 눈으로 볼 수 있다는게 매번 아쉬움으로 남았습니다. 랜선도 직접 꽂아주고, 장애가 생기면 십자 드라이버로 직접 분해하여 고쳐주는등 애착을 갖고 정성을 다해 관리해보고 싶었습니다. 2 네트워크 구성 홈서버 네트워크에 트래픽이 유입되는 경우 [클라이언트] => [외부 프록시 서버] => [공유기] => [프록시서버] => [웹서버 / 스토리지서버] 순으로 흐르게 됩니다. 각 장비별로 정리해 보았습니다. 1) IPTIME T16000M 아이피타임의 가정용 인터넷 공유기 관리콘솔이 친숙하다는 이유로 아이피타임의 랙용 유선 공유기를 설치 하였습니다. 외부에서 트래픽이 아이피타임 공유기로 들어오게 되면 80/443 포트로 들어온 경우 프록시 서버로, 그외 포트는 해당하는 서버로 포트 포워딩 합니다. 추후 서버 증설을 염두하여 랜포트가 많은 모델을 찾다가 이 제품으로 선택했습니다. 금액 : 신품 18만원 2) 리버스프록시 서버 중계 서버란 이유로 가장 저가형으로 당근에서 15만원에 매수한 intel N100 CPU의 미니PC입니다. 중국제 미니 PC에서 흔히 볼 수 있는 저가형 CPU로 내부 프록시 역할만 할 것이므로 사양을 최대한 타협하여 지출을 아꼈습니다. 사용하다 성능이 부족하다 싶으면 업그레이드 할 생각입니다. nginx 를 통해 공유기로 부터 전달된 트래픽을 도메인 기반으로 Reverse proxy 하여 웹서버 혹은 시놀로지 NAS로 전달합니다. 금액 : 중고 15만원 / 사양 - CPU : intel N100 (4Core 4Threds) / RAM : ddr4 16G 3) 웹서버 구입시 가장 고민이 많았던 서버였습니다. 과연 나에게 ecc 램이 필요할까란 생각에 며칠을 깊은 고민에 빠졌지만, 결과는 '필요 없음' 이었습니다. 장애가 생겨 사이트 접속이 단절 된다는 가정을 해봤고, 회원들이 용인해줄 수 있는 단절 시간은 몇분 정도일까 생각 해봤는데 결과는 '하루' 였거든요...ㅎ 웹서버는 랙 사이즈에 맞추다 보니 미들타워 절반 정도로 작은 사이즈의 데스크탑으로 들였습니다. ('이그닉'이라고 아시나요?) CPU가 ecc 지원 모델이라 내심 기대하고 본체를 뜯어보니 메인보드가 ecc 를 non-ecc로 작동 시키는 보드네요. ㅎㅎ centos + apache + mariadb 조합으로 운영되는 웹서버입니다. 이 녀석 역시 당근에서 가져왔습니다. 이 데스크탑을 구매하기 전, IDC에서 반출한 1U를 집에서 반나절 돌렸다가 와이프에게 등짝 스매싱을 당하고 바로 처분 했습니다. 금액 : 중고 60만원 / 사양 - CPU : intel i7 12700 (12Core 20Threds) / RAM : ddr4 32G 4) 시놀로지 나스 시놀로지 나스는 DS1621+ 6bay 모델입니다. 홈 네트워크에서 가장 많은 일을 하는 바쁜 서버입니다. 역할에 비해 부족한 하드웨어 사양으로 인해 시놀로지가 수명을 다하면 헤놀로지로 도전해볼까 진지하게 고민중입니다. 아래는 시놀로지가 하는 일입니다. 참 바쁘죠..? [스토리지 서버] docker + minio 조합으로 Object Storage 서버를 구동하여 웹서버에서 업로드되는 모든 리소스는 시놀로지 나스 도커로 들어가게 됩니다. 웹서버와 시놀로지간 통신은 AWS S3 SDK 를 활용하고 있습니다. [메일서버] 웹서버의 메일서버로 활용되고 있습니다. 메일 수신은 시놀로지 MailPlus Server 가 직접 담당하고 있으며, 메일 송신은 AWS SES SMTP 를 relay 하여 발송하고 있습니다. [원격 백업 서버] 웹서버, 프록시서버, 외부 프록시서버에서 매일 새벽3시에 시놀로지로 원격 백업을 수행합니다. [개발서버 활용] docker에 다양한 개발 환경을 구축해 두고 개발용 서버로 활용합니다. 금액 : 하드 미포함 160만원 / 사양 - CPU : AMD Ryzen V1500B (4Core 8Threds) / RAM : ddr4 16G / hdd : 18T 3 보안 대책 1) 외부 리버스프록시 서버 적용 홈서버로 유입되는 모든 트래픽은 반드시 외부 리버스프록시 서버를 거쳐 홈서버로 오도록 되어 있습니다. 즉, 외부 아이피인 2.2.2.2 로 접속하면 프록시를 통해 우리집 아이피 1.1.1.1 의 서버를 요청합니다. 홈서버는 네트워크 앞단에 물리적 방화벽이 없기 때문에 DDOS등 공격에 취약할 수 밖에 없습니다. 만의 하나 DDOS가 유입되는 경우 소프트웨어적으로 대응할 수 밖에 없으며, 아이피 변경으로 우회 시키려 해도 맥Address 를 변경해야 하기 때문에 쉬운 일은 아닙니다. 그래서 외부 프록시서버로 적어도 L3/L4 방화벽이 제공되는 AWS 의 lightsail 을 이용 중입니다. 우리집 공인IP를 외부에서 은폐 시킬 수 있고, 방화벽을 통과한 DDOS가 유입 되더라도 외부 프록시서버로 먼저 유입 되기 때문에 lightsail의 아이피만 바꾸면 그만입니다. 무엇보다 라이트세일은 아이피 변경이 매우 즉각적이고 쉽습니다. 심지어 저렴합니다. DDOS는 막는게 아니고 피하거나 버텨 내는거라 배웠습니다. 저는 빨리 도망갈 수 있는 길을 택했습니다. 사양 - CPU : 2vcpu / RAM : 2G 2) 외부 프록시 서버로 lightsail 을 택한 이유 리버스 프록시 서버이기 때문에 비용이 적은 VPS를 택했습니다. GCP, 오라클 클라우드, 호스팅어등 다양한 VPS 서비스가 있지만, 웹서비스 구축을 위해 AWS에서 S3, Cloud Front, SES, Route53 등의 서비스를 사용하고 있기에 관리 측면에서 AWS lightsail을 택했습니다. 또한, 앞서 언급된 DDOS시 즉각적인 아이피 변경을 통해 어렵지 않게 DDOS 트래픽을 증발시켜 버릴 수 있다는 장점이 있었습니다. 3) lightsail 트래픽 정책의 아쉬운 점 그리고 대안 보안을 위해 외부 프록시서버를 거치도록 하였지만, 홈서버에서 발생되는 트래픽은 모두 '비용' 이라는 점이 문제입니다. lightsail 2vcpu / ram 2G 상품은 월간 3T 트래픽을 제공하는데, 타사 VPC 서비스에 비해 상대적으로 적은양의 트래픽을 제공하는 점이 아쉬운 점입니다. 유념 할 점은 3T 트래픽 양은 in/out을 포함한 사용량이라는 것입니다. 즉, 클라이언트가 사이트의 10M 짜리 이미지를 요청한 경우 lightsail 프록시 서버가 홈서버로부터 이미지를 받아와 클라이언트에게 보여주기 까지 in/out 트래픽을 합쳐 총 20M의 트래픽을 소진한다는 겁니다. 물론, 홈서버에서 발생한 트래픽까지 포함한다면 30M가 됩니다. 불필요한 트래픽 누수를 막기 위해 lightsail 프록시 서버에는 nginx 를 통해 캐싱을 활성화 해두었습니다. 클라이언트를 통해 한번 호출된 리소스는 lightsail 에서 7일간 재사용 되며, 30일간 호출되지 않은 리소스의 경우 로컬에서 삭제하는 룰로 셋팅하였습니다. 4 홈서버를 운영하며 느낀 점 가정 인터넷 회선은 여러 위험 요인이 도사리고 있고 그 위험 부담은 본인이 책임져야 한다는 부담감도 공존합니다. 실수로 ssh 포트를 닫았을때 대신 포트를 열어주거나, 서버 전원 버튼을 대신 눌러줄 사람이 항시 대기하고 있다는 안도감은 IDC의 장점이기도 합니다. 저는 홈서버를 비즈니스 목적으로 사용하고 있습니다. 갑작스런 서버 장애가 제 비즈니스에 치명적이지 않고 용인된다는 점이 비즈니스 목적으로 사용할 수 있는 이유입니다. 순간적인 순단 현상이라도 비즈니스에 치명적이라면 절대 홈서버는 비즈니스로 적합하지 않다 생각합니다. 그럼에도 홈서버가 제공해주는 이점은 많습니다. 안정성 문제를 논외로 한다면, IDC비해 후한 회선 대역폭, 상면비가 없다는 점, 반드시 1U이지 않아도 되는 하드웨어 구성의 자유로움, 적은 비용으로 서버 공부 할 수 있다는 점, 서버에 애착을 가질 수 있다는점.. 그리고, 방안에 크고 못생기고 시끄러운 서버랙을 볼 때 마다 이런 짓을 이해해주고 응원해주는 우리 재무부장관님께 감사함을 느낄 수 있다는 것은 큰 장점입니다. 장관님 감사합니다. .article_title{font-weight:bold !important;display: block;padding-bottom:10px;border-bottom:1px solid #ddd;font-size:30px;letter-spacing:-1px;} .article_title em{display:inline-block;vertical-align:middle;margin-right: 5px;width:30px;line-height:30px;text-align:center;border-radius:1px;font-style:normal;background:#333;font-size:16px;color:white;font-weight:bold;margin-top:-2px;} @media screen and (max-width: 750px){ .article_title{font-size:20px;} .article_title em{width: 25px;line-height:25px;font-size:14px;} }

[nginx] reverse proxy 에서 프록시 캐시서버(CDN) 적용하기 (centos 7) 사진등 용량이 큰 리소스를 별도 서버에서 reverse proxy하여 웹사이트에 노출시키고 있다면 접속자에게 1M 용량의 이미지를 노출시킬 때 프록싱간 in/out bound 를 합쳐 트래픽을 총 3M를 소진하게 되는데, 접속자를 통해 한번 호출된 파일을 프록시 서버에 캐시파일로 저장해 두고 반환한다면 out-bound 트래픽 1M만 소진하게 되어 트래픽을 1/3 수준으로 절감할 수 있다. 이를 Cache server (CDN)이라고 하며, nginx 에서는 간단한 설정으로 캐시서버 구축이 가능하다. 캐시서버가 필요하게 된 배경 내가 운영중인 사진 블로그는 웹서버와 사진이 보관된 스토리지 서버가 분리되어 있으며, 글 마다 노출되는 사진 파일이 총 10M이상 된다. 접속자 한명이 블로그 글 하나를 조회하게 되면 프록시 서버와 스토리지서버(사진이 보관된)간 통신하는 과정에 총 30M 이상의 트래픽을 소진하게 되는데 100명의 접속자가 글을 조회 한다면 3G 이상의 트래픽을 유발 시킨다. [접속자] <-- out 10M 소진 -- [프록시서버] <-- in/out 20M --> [스토리지서버] 블로그 글에서 제공되는 사진은 10M지만, 총 30M 트래픽을 소진하게 됨. 따라서, 캐시서버를 구축하여 이미지 파일을 프록시서버에 보관하게 된다면 트래픽이 스토리지 서버까지 다녀올 필요가 없기 때문에 클라이언트에게 out-bound 되는 1G만 소진하면 된다. nginx.conf 설정 먼저, 캐시와 temp등의 경로 설정을 위해 nginx.conf 파일을 수정한다. # /etc/nginx/nginx.conf vi로 설정 파일을 열어 아래와 같이 설정한다. ... http { ... proxy_cache_path /etc/nginx/cache/ levels=1:2 keys_zone=cache_zone:40m inactive=7d max_size=100m; proxy_temp_path /etc/nginx/cache_temp/; include /etc/nginx/conf.d/*.conf; ... } 1) proxy_cache_path : 캐시 저장소 경로를 설정한다. - levels : 하위 디렉토리의 깊이 - key_zone : 캐시존 이름 - inactive : 캐시 파일이 정해진 기간만큼 사용되지 않는다면 캐시에서 제거 2) proxy_temp_path : temp 파일이 저장될 경로를 설정한다. vietualhost 설정 특정 호스팅에 캐시를 적용하기 위해 conf 파일을 열어 세부 설정을 한다. # vi /etc/nginx/conf.d/000.net.conf (virtual host 설정을 위해 생성한 conf 파일을 연다.) virtual host 의 conf 파일을 vi로 연 다음 아래와 같이 작성한다. server { location / { ... # cache proxy_cache cache_zone; # cache data 7일 동안 보관 expires 7d; # cache 업데이트 충돌시 잠금시간 proxy_cache_lock_timeout 5s; # cache method 설정 proxy_cache_methods GET HEAD POST; # cache 결과코드를 20분동안 보관 proxy_cache_valid 200 401 301 304 20m; # cache 상태를 헤더로 보여줌. (MISS, HIT 등) add_header X-Proxy-Cache $upstream_cache_status; # cache-control 설정 add_header Cache-Control "public"; # 다음 클라이언트 헤더 무시 proxy_ignore_headers X-Accel-Expires Expires Cache-Control; ... } } 설정이 완료 되었다면 nginx 를 재시작 한다. # systemctl restart nginx 브라우저에서 캐싱 여부 확인하기 설정을 모두 마쳤다면, 프록싱이 적용된 사이트를 접속하여 브라우저 작업관리자를 통해 캐싱 여부를 확인해본다. 1) 최초 요청으로 캐싱되지 않은 이미지가 노출된 경우 > X-Proxy-Caches : MISS 노출 2) 캐싱이 적용된 이미지인 경우 > X-Proxy-Caches : HIT 노출

CentOS 에서 CPU 온도 체크하기 (lm_sensors) centos(리눅스)에서는 간편하게 cpu 온도를 확인할 수 있는 모니터링 툴을 제공한다. ln_sensors 설치 cpu 온도 모니터링 툴 lm_sensors 를 yum을 통해 설치한다. # yum install lm_sensors 설치 후 대상 하드웨어를 인식 시킨다. 다만, vm 환경에서는 하드웨어 인식이 안될 수 있으니 lm_sensors 사용 가능 여부를 확인한다. # sensors-detect ln_sensors 사용 방법 lm_sensors는 명령어 한번으로 간편하게 사용 가능하다. # sensors sensors 명령어만 치면 바로 모니터링 할 수 있다. - Package : cpu의 평균 온도를 보여준다. - Core : 각 Core별 온도를 보여준다. CPU Core 개수에 따라 노출되는 개수가 다르다.

리눅스 실시간 모니터링 도구 htop 사용하기 기본적으로 리눅스에는 실시간 모니터링을 위한 도구인 'top' 을 제공한다. # top top 을 실행하면 아래와 같은 화면의 모니터링 정보가 노출 되는데 cpu, 메모리, 로드율등 기본적인 현황을 확인할 수 있다. htop으로 보다 세부적인 모니터링 htop 은 top 보다 세부적인 실시간 모니터링 정보를 확인할 수 있는 도구로 아래와 같이 yum으로 설치하여 사용할 수 있다. # yum install htop # htop 실행 화면은 다음과 같은데, cpu의 각 스레드별로 사용률을 확인할 수 있고, 다양한 설정을 통해 실시간 내역을 명확하게 확인 가능하다.

[mariadb] mariadb table schema (테이블 명세) 출력 쿼리 mysql table 명세서를 아래 쿼리를 통해 출력할 수 있다. 명세서 작성시 유용하게 활용할 수 있다. table schema 추출 아래 스키마명, 테이블명을 적절히 수정하여 사용한다. SELECT t1.table_name, t1.table_comment, column_name, data_type, column_type, column_key, is_nullable, column_default, extra, column_comment FROM (SELECT table_name, table_comment FROM information_schema.TABLES WHERE table_schema='스키마명' AND table_name='테이블명') t1, (SELECT table_name, column_name, data_type, column_type, column_key, is_nullable, column_default, extra, column_comment, ordinal_position FROM information_schema.COLUMNS WHERE table_schema='스키마명' AND table_name='테이블명') t2 WHERE t1.table_name = t2.table_name ORDER BY t1.table_name, ordinal_position; 아래와 같이 결과가 출력된다.

[centOS] 경로내 .DS_Store 파일 일괄 삭제 .DS_Store 파일은 맥에서 디렉토리 접근시 자동 생성되는 메타데이터를 저장하는 '숨김 파일'이다. 윈도우의 thumb.db 과 같은 맥락의 파일이다. 아래와 같이 맥에서 생성되는 .DS_Store 파일을 일괄 삭제할 수 있다. .DS_Store 일괄 삭제 아래와 일괄 삭제. #find . -type f -name .DS_Store -delete

[centOS] 버퍼메모리 초기화 방법 프로그램의 과부하 혹은 메모리 누수로 인해 버퍼메모리가 과도하게 발생한 경우 아래와 같이 강제로 메모리를 초기화 할 수 있다. 퍼버메모리 초기화 아래와 같이 버퍼 메모리를 초기화 할 수 있다. #echo 3 > /proc/sys/vm/drop_cache

[centOS] 현재 FTP/SSH 접속해있는 접속자 ip 확인하기 현재 FTP와 SSH에 접속해있는 접속 ip를 확인할 수 있다. 현재 FTP/SSH 접속 ip확인 아래와 같이 확인 #last | grep logged | awk '{print $1,$3}' | sort | uniq -c | sort -n | awk '{print $2,$3}'

[centOS] hosts.allow 와 hosts.deny 설정으로 서버 접근 ip 차단 iptable에서 아이피 접근을 차단할 수 있지만, hosts.allow 와 hosts.deny 파일 설정을 통해 트래픽 유형별로 세분화하여 아이피 차단/허용 처리 할 수 있다. hosts.allow 로 아이피 차단 아이피 접근 차단 방법을 안내한다. # vi /etc/hosts.deny 설정 파일을 vi로 연다. ... ALL: ALL 위와 같이 모든 아이피를 차단할 수 있으며, 이 경우 허용하고자 하는 특정 아이피만 hosts.allow 에서 열어줘야 한다. 입력 방법은 아래 참고. ... ALL: 111.222.333.444, 222.333.444.555 위와 같이 차단할 아이피를 지정할 수 있다. 여러 아이피인 경우 콤마(,)로 입력한다. ... sendmail: 111.222.333.444, 222.333.444.555 sendmail: ALL 위와 같이 sendmail 에 대한 접근 차단을 할 수도 있다. hosts.allow 로 아이피 허용 아이피 접근 허용 방법을 안내한다. # vi /etc/hosts.allow 설정 파일을 vi로 연다. ... ALL: 111.222.333.444, 222.333.444.555 위와 같이 허용할 아이피를 지정할 수 있다. 여러 아이피인 경우 콤마(,)로 입력한다. ... sendmail: 111.222.333.444, 222.333.444.555 위와 같이 sendmail 에 대한 접근 허용을 할 수도 있다.

[centOS] 포트별 접속자 수를 출력하는 sh 스크립트 파일 작성 현재 포트별 접속자 수를 출력하는 스크립트. 스크립트 파일 작성 vi로 스크립트 파일을 작성한다. # vi /var/log/port_stat.sh 파일 내용에 아래와 같이 입력한다. #!/bin/bash ports=("443" "80" "21000" "20000" "3306") for port in "${ports[@]}"; do count=$(netstat -an | grep ":${port}" | wc -l) echo "Port ${port} => ${count}" done 위 스크립트를 실행하면, 아래와 같이 포트별 접속자 수가 출력된다. # /var/log/port_stat.sh

[centOS] 아파치 access_log 에서 특정 시간동안의 아이피별 접속 횟수 추출하기 아파치의 access_log 파일 내용을 활용하여 특정 기간동안 아이피별로 접속 횟수를 추출해주는 스크립트 파일. 오늘동안의 아이피별 접속 횟수 출력 vi로 sh 파일을 생성한다. # vi /var/log/today_log.sh 파일 내용에 아래와 같이 입력한다. #!/bin/bash # 로케일을 영어(미국)으로 변경 export LC_TIME="en_US.UTF-8" LOG_FILES=( "/var/log/httpd/access_log" #"/home/zigger.net/access_log" #"/home/bboggi.com/access_log" #"/home/note.chanyeongpark.com/access_log" ) DATE=$(date +"%d/%b/%Y") for LOG_FILE in "${LOG_FILES[@]}"; do output=$(grep "${DATE}" "${LOG_FILE}" | grep -Ev '(\.js|\.css|\.woff|\.jpg|\.jpeg|\.gif|\.png|\.bmp|\.txt)' | awk '{ip_count[$1]++} END {for (ip in ip_count) {print ip, ip_count[ip]}}' | sort -k2,2n) echo "[ Log File: ${LOG_FILE} ]" echo "$output" echo echo ${DATE} done 위 스크립트중 LOG_FILES 배열은 추출할 다수의 로그 파일 경로를 지정하며, grep -Ev '(\.js|\.css|\.woff|\.jpg|\.jpeg|\.gif|\.png|\.bmp|\.txt)' 는 js, css, jpg 등 리소스 파일은 제외하고 순수한 웹페이지 파일 접속 아이피만을 추출한다. 위 스크립트를 실행하면, 아래와 같이 아이피별 접속 횟수가 출력된다. # /var/log/today_log.sh 현재 '시' 기준 아이피별 접속 횟수 출력 현재 '시'를 기준으로 아이피별 접속 횟수는 아래와 같이 작성한다. #!/bin/bash # 로케일을 영어(미국)으로 변경 export LC_TIME="en_US.UTF-8" # 로그 파일 경로 설정 LOG_FILES=( "/var/log/httpd/access_log" ) # 현재 시간을 구해서 DATE 변수에 저장 (한 시간 전으로 설정) DATE=$(date +"%d/%b/%Y:%H") for LOG_FILE in "${LOG_FILES[@]}"; do # 해당 로그 파일에서 최근 한 시간 동안의 접속 기록을 필터링하고 IP 주소별로 카운트 output=$(grep "${DATE}" "${LOG_FILE}" | grep -Ev '(\.js|\.css|\.woff|\.jpg|\.jpeg|\.gif|\.png|\.bmp|\.txt)' | awk '{ip_count[$1]++} END {for (ip in ip_count) {print ip, ip_count[ip]}}' | sort -k2,2n) echo "[ Log File: ${LOG_FILE} ]" echo "$output" echo echo ${DATE} done