Recent Posts
-
[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;} }
-
[시놀로지] MailPlus Server 에서 AWS SMTP(SES)를 발송 릴레이 서버로 사용하기
시놀로지 NAS로 메일서버 구축시 문제점 시놀로지 NAS는 대부분 가정에서 운영된다. 시놀로지 메일플러스(MailPlus Server)를 통해 메일서버를 운영할때 가정에 제공되는 IP가 불량 아이피일 가능성이 클 뿐만 아니라, 수신 메일서버에서 스팸으로 필터링 되지 않기 위한 DKIM, whilte domain등 사전 작업은 만만치 않은 일이다. AWS에서 제공하는 SES(Simple Email Service)에서 SMTP를 제공받아 시놀로지 Mail plus의 릴레이 서버로 연동한다면 이 복잡한 작업을 AWS에 의존하여 메일서버를 운영할 수 있게 된다. 리전 선택 및 도메인 등록 SES 공식 웹페이지 https://ap-northeast-2.console.aws.amazon.com/ses/home 을 방문하여 리전을 서울로 변경한다. 도메인 등록을 위해 [구성 - 자격 증명] - [자격 증명 생성]을 클릭한다. 버튼을 클릭하여 자격 증명 화면에 접속한 다음 '보안 인증 유형'을 '도메인'으로 선택하고 '도메인' 입력 란에 이메일에 사용되는 도메인을 입력한다. (ex: email@chanyeongpark.com 인 경우 chanyeongpark.com 입력) 자격 증명 생성 과정에서 DKIM은 기본적으로 설정되니 따로 건드릴 설정 없이 바로 [자격 증명 생성] 버튼을 클릭하여 생성을 완료한다. 도메인 DKIM 레코드 설정 도메인에 대한 메일 신뢰도 검증을 위한 DKIM 설정을 위해 생성된 자격 증명 상세 화면으로 이동한다. 도메인 DNS에서 등록한 CNAME 레코드 값을 확인할 수 있다. 도메인에 레코드 등록을 위해 DNS 관리 화면으로 이동한다. 나의 경우 AWS route53 서비르를 통해 레코드를 추가했으나, 가비아, 후이즈 등 타사 DNS 관리 서비스의 레코드 등록 방법도 route53과 크게 다르지 않다. route53 서비스로 들어가 chanyeongpark.com 에 대한 [레코드 생성]을 클릭한다. 위와 같이 '레코드 유형'을 CNAME으로 선택한 다음 앞서 SES 에서 발급 받은 레코드 이름과 값을 복사하여 붙여넣는다. 발급 받은 3개의 레코드 모두 생성해 준다. SES SMTP 발급 도메인 DKIM 레코드 등록이 완료 되었다면, 메일 발송을 하기 위한 SMTP를 발급 받는다. 발급 받을 SMTP가 시놀로지와 연동될 정보다. [SMTP 설정 - SMTP 보안 인증 생성] 을 클릭하면, AWS IAM(인증 정보 관리) 자격 증명 생성 화면으로 이동하게 된다. SMTP 자격증명 정보가 자동으로 입력되므로 [사용자 생성] 을 클릭하여 자격 증명을 생성한다. 자격증명 생성이 완료되면 위와 같이 자격 증명 정보가 표시되는데, 이 정보가 시놀로지와 SES가 연동될 인증 정보다. SMTP 비밀번호는 이 화면에서만 확인 하거나 다운로드 가능하며 페이지를 벗어나는 경우 다시 확인할 수 없으니 반드시 메모장에 기록해 둔다. 시놀로지 MailPlus Server 에서 SES SMTP 연동 AWS SES 에서 SMTP 발급까지 완료 되었다면 시놀로지에서 발급 받은 SMTP를 릴레이로 연동할 순서다. 시놀로지 DMS에 접속하여 [Synology MailPlus Server] 패키지를 실행한 다음 [메일 배달 - 제공] 으로 이동하여 위와 같이 설정한 다음 [적용]을 클릭한다. 이후부터 시놀로지에서 메일을 발송하는 경우 NAS에서 직접 발송하지 않고, AWS SES의 SMTP로 릴레이하여 발송하게 된다.
-
[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 개수에 따라 노출되는 개수가 다르다.
-
route53 상태검사(health check)로 내 서버 접속상태 수시로 체크하기
모든 리전(국가)에서의 내 서버의 접속 상태를 수시로 자동 체크해주는 route53 '상태검사(health check)' 기능을 소개한다. 지정해 놓은 외부 접속 주소를 route53이 수시로 체크 해주고, 접속 불능 상태가 되었다면 이메일로 알림 메일을 보내준다. route53 상태 검사 생성 AWS route53 콘솔을 방문한 다음 (https://us-east-1.console.aws.amazon.com/route53/home) 좌측 메뉴에서 [상태 검사]를 클릭한다. 상단 메뉴바에서 [상태 검사 생성]을 클릭한다. 위와 같이 상태 체크 정보를 입력후 [다음]을 클릭하면 즉시 상태 검사를 수행한다. 1) 모니터링 대상 : 외부 목적지의 접속을 시도해야 하기 때문에 '엔드포인트' 선택 2) 엔드포인트 지정 기준 : '도메인 이름'을 선택하여 도메인 주소로 접속 시도 요청. 접속 시도할 정보를 입력해준다. 상태 체크가 시작되면 아래와 같이 현황을 보여준다. 접속 리전 설정 상태 검사할 접속 국가를 설정하려면, 상태 검사 생성 과정에서 [고급 구성]을 클릭하여 리전을 선택해준다. 상태 체크 비용 route53 의 상태체크 기능은 엔드포인트 개수에 따른 비용이 과금된다. https://aws.amazon.com/ko/route53/pricing/#Health_Checks 나는 AWS 외 엔드포인트로 설정 하였기 때문에 월별 0.75USD 비용이 청구된다. 한화로 천원 가량. https로 요청한다면 2,600원 가량. (세상에 공짜는 없다.)
-
centos7에서 reverse proxy 서버 구축을 위한 nginx 설치 및 설정
하나의 아이피로 연결된 같은 네트워크내 다수의 서버를 nginx reverse proxy 서버를 통해 프록싱 해본다. reverse proxy가 필요한 상황 나의 경우 아래 두가지 이유 때문에 리버스프록시 서버가 필요한 상황이었다. 1) 다수의 서버가 연결되어있는 게이트웨이에 단 하나의 외부 아이피만 존재하는 상황. 외부 트래픽이 유입하면 reverse proxy 서버를 통해 사설아이피로 트래픽을 유도하여 특정 서버로 유입되도록 한다. 2) 내가 운영중인 메인서버의 공인IP가 외부로 유출되면 DDOS 공격에 취약해지기 때문에 공인 IP를 은폐할 목적. AWS에 프록시 서버를 하나 더 두고 내 서버를 프록싱 하면 웹사이트의 외부 IP는 AWS의 IP로 노출된다. 프록시 서버로 nginx를 선택한 이유 nginx는 apache의 대량 트래픽 처리시 발생하는 부하 문제를 보완하기 위해 탄생한 웹서버다. 즉, 다수 서버에 유입될 트래픽이 모두 거쳐가게 되는 프록시 서버에는 nginx만큼 효율이 좋은 웹서버는 없었기 때문이다. 심지어 apache보다 가볍고, 설정 또한 직관적이고 쉽다. 최소 사양으로 구동되는 프록시 서버에 nginx보다 적합한 웹서버는 없다는 생각이다. nginx 설치 먼저, nginx를 설치한다. 내가 사용중인 centos7 OS는 공식 yum서버에서 nginx를 제공하지 않기 때문에 별도의 repo를 yum에 외부 저장소를 등록해주고 nginx를 설치한다. # vi /etc/yum.repos.d/nginx.repo yum.repos.d 디렉토리 내에 repo 파일을 하나 만들어 주고, 아래와 같이 vi로 작성하여 저장한다. [nginx] name=nginx repo baseurl=http://nginx.org/packages/centos/7/$basearch/ gpgcheck=0 enabled=1 외부 저장소 등록이 완료 되었다면 yum 을 통해 nginx를 설치한다. # yum install nginx 클라이언트 최대 전송량 설정 클라이언트가 nginx 프록시 서버에서 목적지 서버로 요청할 때 body의 최대 전송량을 설정해준다. nginx의 기본 client_max_body_size는 1M로, 허용량을 초과하게 되면 요청 자체가 되지 않기 때문에 반드시 늘려줘야 한다. client_max_body_size를 모든 호스트에 대해 적용해 주려면 # vi /etc/nginx/nginx.conf 를 vi로 열어 http { ... client_max_body_size 40000M; ... } 를 추가해 주거나, 호스팅 개별적으로 적용해 주려면 # vi /etc/nginx/conf.d/[hostname].conf 를 vi로 열어 server { ... client_max_body_size 40000M; ... } 를 추가해준다. reverse proxy 구성을 위한 설정 reverse proxy 구성을 위해 설정파일을 생성해야 한다. #cd /etc/nginx/conf.d nginx 설정 파일은 /etc/nginx/conf.d/ 경로내에 저장한다. 파일명은 아무렇게나 설정해도 되지만, 반드시 확장자는 .conf 로 저장해야 한다. chanyeongpark.com 도메인에 대한 virtual host 및 reverse proxy 설정을 위해 아래와 같이 새로운 설정 파일을 생성한다. 나는 식별이 용이하도록 도메인 이름으로 설정 파일을 생성했다. # vi /etc/nginx/conf.d/note.chanyeongpark.com.conf vi 로 설정파일에 아래와 같이 내용을 작성했다. server { listen 80; #80번 포트로 들어오는 경우에만 실행 server_name note.chanyeongpark.com; #접속 주소가 note.chanyeongpark.com 인 경우에만 실행 # root /home/note.chanyeongpark.com/public_html; #virtual host 경로 설정 # index index.html #index 파일명 설정 return 301 https://note.chanyeongpark.com; #80번포트로 접속한 경우 https://로 리다이렉팅 } server { listen 443 ssl; #443포트로 접속한 경우에만 실행 server_name note.chanyeongpark.com; #접속 주소가 note.chanyeongpark.com 인 경우에만 실행 root /home/note.chanyeongpark.com/public_html; #virtual host 경로 설정 error_log /home/note.chanyeongpark.com/error_log; #error log 파일 위치 access_log /home/note.chanyeongpark.com/access_log; #access log 파일 위치 ssl_certificate /etc/letsencrypt/live/note.chanyeongpark.com/fullchain.pem; #ssl 적용을 위한 pem 위치 ssl_certificate_key /etc/letsencrypt/live/note.chanyeongpark.com/privkey.pem; #ssl 적용을 위한 privatekey 위치 location / { proxy_pass http://111.222.333.444/; #111.222.333.444를 목적지로 포워딩 한다. proxy_http_version 1.1; #proxy http 버전을 1.1로 설정(nginx 공식 문서에서 1.1로 권장함, 기본값은 1.0) proxy_set_header Host $http_host; #http host 정보를 header로 전달한다. proxy_set_header X-Real-IP $remote_addr; #요청 클라이언트의 IP를 header로 전달한다. proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } http로 접근한 경우 ssl이 적용된 도메인으로 리다이렉트 되어야 하기 때문에 virtual host 경로를 지정하여 인증서를 발급(재발급) 받을 수 있도록 하였으며, http 접속시 https로 301 리다이렉트 되도록 구성 하였다. 443포트로 접속시에는 요청 클라이언트의 정보를 header로 실어 목적지 서버로 전달할 수 있도록 설정하였다. # root /home/note.chanyeongpark.com/public_html; # index index.html 위 구문은 let's encrypt에서 인증서 발급시 http로 접속하는 경우 홈디렉토리로 연결 되어야 하기네 필요한 구문으로, ssl 연결 이후 연장할 때는 불필요하므로 주석처리 해뒀다. proxy_http_version 기본값 1.0으로 사용시 시놀로지 DSM을 reverse proxy 하는 경우 모바일에서 js, css 등 리소스를 로드하지 못하는 현상이 발견 되었다.
-
리눅스 실시간 모니터링 도구 htop 사용하기
기본적으로 리눅스에는 실시간 모니터링을 위한 도구인 'top' 을 제공한다. # top top 을 실행하면 아래와 같은 화면의 모니터링 정보가 노출 되는데 cpu, 메모리, 로드율등 기본적인 현황을 확인할 수 있다. htop으로 보다 세부적인 모니터링 htop 은 top 보다 세부적인 실시간 모니터링 정보를 확인할 수 있는 도구로 아래와 같이 yum으로 설치하여 사용할 수 있다. # yum install htop # htop 실행 화면은 다음과 같은데, cpu의 각 스레드별로 사용률을 확인할 수 있고, 다양한 설정을 통해 실시간 내역을 명확하게 확인 가능하다.
-
route53 에서 '루트 도메인' 접속시 'www.도메인' 으로 리다이렉트 시키는 방법 (feat. cloudfront + s3 + ACL)
route53 에 자신의 도메인을 등록하여 dns 서비스를 이용하는 경우 dns 국제 규약에 의거 루트 도메인에는 cname을 적용할 수 없는데 루트 도메인에 cname을 등록해야만 하는 상황인 경우 (chanyeongpark.com 과 www.chanyeongpark.com 모두 cname을 적용하고 싶을 때), 대안으로 cloud-front 와 s3를 활용하여 'www.chanyeongpark.com' 으로 포워딩 시킬 수 있는 방법이 있다. 루트도메인에 cname을 적용해야 하는 배경 나는 홈서버를 운영중이다. 가정용 인터넷 회선은 이따금씩 할당 받는 ip가 변경되기 때문에 필연적으로 DDNS 서비스를 사용하여 변경된 ip를 도메인으로 참조해야 한다. (0000.synology.me) 아이피가 변경될 때 마다 도메인이 바라보는 A 레코드 아이피를 바꿔줄 수 없으니 당연히 레코드를 cname 으로 설정하여 0000.synology.me 를 참조하도록 설정하고 있다. 최근 AWS route53 으로 도메인 네임서버를 이관 하였는데, route53은 루트 도메인(chanyeongpark.com)에 cname을 설정할 수 없어 곤란한 상황. AWS 여러 서비스를 살펴보니, 오브젝트스토리지 서비스인 's3'와 CDN 서비스인 'cloudfront' 서비스를 조합하면 루트도메인(chanyeongpark.com) 접속시 'www.chanyeongpark.com'으로 리다이렉트 시켜 대응할 수 있다는 사실을 알았다. 작동되는 시나리오 chanyeongpark.com 접속시 리다이렉트가 작동되는 시나리오는 아래와 같다. [chanyeongpark.com 요청] -> [cloudfront : https 프록싱] -> [s3 : http 연결] -> [www.chanyeongpark.com redirect] 접속자가 도메인 요청시 cloudfront endpoint로 연결되며, cloudfront는 다시 s3의 정적 웹사이트 endpoint로 연결하면, s3가 정적 웹사이트에 설정된 url로 redirect하는 방식이다. s3 버킷 생성 https://s3.console.aws.amazon.com/s3/get-started?region=ap-northeast-2&bucketType=general®ion=ap-northeast-2 AWS s3는 '정적호스팅' 기능을 제공한다. s3 버킷에 업로드된 파일을 웹에서 열 수 있도록 url을 제공하는 기능인데, 이 정적호스팅은 '정적 웹 사이트 호스팅' 과 '객체에 대한 요청 리디렉션' 두가지 속성을 제공한다. 1) 정적 웹 호스팅 : 저킷 접속시 버킷에 업로드된 특정 html 파일이 열리도록 하는 옵션 2) 객체에 대한 요청 리디렉션 : 버킷 접속시 다른 버킷이나 외부 url로 리디렉션 시키는 옵션 s3 버킷 접속시 'www.chanyeongpark.com'으로 접속될 수 있도록 '객체에 대한 요청 리디렉션' 옵션을 활용해 본다. 우선 새로운 s3 버킷을 만든다. 어떠한 이름으로 생성해도 무관하나, 나는 식별을 위해 버킷명을 도메인명으로 설정했다. 생성된 버킷명을 클릭하여 설정 화면으로 이동한 뒤 [속성]을 클릭한다. 스크롤을 조금 내려 '정적 웹 사이트 호스팅' 섹션에서 [편집]을 클릭한다. 아래와 같이 정적 웹 사이트 호스팅을 설정한다. chanyeongpark.com 접속시 https 도메인으로 접속 되어야 하기 때문에 '프로토콜'은 https를 선택한다. cloudfront 연동을 위한 s3 버킷 생성은 모두 끝났다. 여기서 cloudfront 와 연동시 필요한 정보는 endpoint 다. cloudfront 연동에 앞서 https://us-east-1.console.aws.amazon.com/cloudfront/v4/home?region=ap-northeast-2 route53와 s3 버킷 연동만으로 리다이렉트 가능하다면 얼마나 좋을까. 아쉽게도 s3 정적호스팅 endpoint는 https 엔드포인트 url을 제공하지 않는다. 내가 운영하는 사이트는 https를 기본으로 사용하고 있기 때문에 인증서가 적용된 https 주소가 필요한 상황. 그래서 cloudfront 추가 연동이 필요하다. 그 전에, cloudfront 사용을 위해선 SSL 인증서가 미리 준비되어 있어야 하는데, 다행스럽게도, AWS는 리소스 사용을 위해 필요한 인증서를 무료로 제공해주고 있다. AWS certificate manager(ACM)에서 인증서 발급 https://us-east-1.console.aws.amazon.com/acm/home?region=us-east-1#/certificates/request AWS certificate manager(ACM)에서 인증서를 발급받아 보자. 주의 할 점은 '버지니아 북부(us-east-1)' 에서 발급받은 인증서만 cloudfront 에 적용 가능하니 반드시 리전부터 변경하고 보자. '퍼블릭 인증서 요청'을 선택한 뒤 아래 [다음] 버튼을 클릭한다. 접속할 루트도메인 주소를 입력하고 하단 [요청]을 클릭하여 발급 요청한다. 약 5분정도 기다리니 인증서가 성공적으로 발급 되었다. cloudfront 생성 및 s3 연동 https://us-east-1.console.aws.amazon.com/cloudfront/v4/home?region=ap-northeast-2#/distributions cloudfront 에서 새로운 '배포'를 생성하여 s3와 연동한다. 화면 상단 [배포 생성]을 클릭하여 cloudfront를 생성한다. 생성화면의 'Choose origin domain'을 클릭하여, 앞서 생성한 s3 엔드포인트를 선택한다. '뷰어 프로토콜 정책' 중 'Redirect HTTP to HTTPS'를 클릭한다. 엔드포인트 접속시 http와 https 둘다 접속을 허용하지만, http 접속 시에는 https 로 강제 리다이렉트 시키기 위함이다. '대체 도메인 이름(cname)'에 루트 도메인(chanyeongpark.com)을 입력하고 앞서 생성한 SSL 인증서를 선택한 다음 [배포 생성]을 클릭하여 s3와의 연동을 완료한다. route53 에서 루트도메인 레코드에 cloudfront 연결 https://us-east-1.console.aws.amazon.com/route53/v2/home?region=ap-northeast-2#Dashboard 드디어 마지막 단계! route53 에서 루트도메인에 방금 만든 cloudfront 배포 엔드포인트를 연동한다. dns 호스팅 영역을 선택한 다음 [레코드 생성]을 선택한다. 위와 같이 [별칭]을 선택하면 추가 선택 항목이 노출 되는데 '트래픽 라우팅 대상' 에서 'CloudFront 배포에 대한 별칭', '배포 선택' 에서 방금 만든 cloudfront 엔드포인트를 선택한 다음 [레코드 생성]을 클릭하여 모든 과정을 마무리 한다. 마지막으로, 브라우저 창에서 루트도메인 접속시 'www.도메인'으로 리다이렉션이 잘 되는지 확인한다.
-
[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
-
AWS PHP sdk로 API Gateway 에 api 키 생성, 사용량계획 연결, 키 삭제
API Gateway에 요율 및 제한량을 api 유저별로 개별 설정해 주기 위해 api 키 생성후 사용량 계획 연결이 필요한데, php sdk를 통해 api 키 생성 및 미리 만들어 놓은 사용량계획을 연결해 주는 방법. IAM 에서 access key 와 secret key 생성 아래 링크를 접속하여 IAM 에서 API에 사용할 access key 와 secret key를 미리 생성해둔다. https://console.aws.amazon.com/iam/home?region=ap-northeast-2#/security_credentials 키 생성 및 사용계획 연결 아래와 같이 구현 가능한데, region, 사용량계획id 등을 적절히 수정해준다. use Aws\Credentials\Credentials; use Aws\Signature\SignatureV4; use Aws\ApiGateway\ApiGatewayClient; // signature 생성 $accessKey = 'access key'; $secretKey = 'srcret key'; // AWS 자격 증명 및 API Gateway 클라이언트 설정 $credentials = new Credentials($accessKey, $secretKey); $apiGatewayClient = new ApiGatewayClient([ 'region' => 'ap-northeast-2', 'version' => 'latest', 'credentials' => $credentials, 'signature' => new SignatureV4('apigateway', 'ap-northeast-2') // region 설정 ]); // API 키 생성 $result = $apiGatewayClient->createApiKey([ 'name' => 'userskey123', // 중복되지 않는 고유한 이름으로 수정 'enabled' => true, // 활성화 여부 'description' => 'hello', // 메모 'value' => 'codehere'.rand(), // 코드를 수동 생성하려면 입력. ]); $apiKeyId = $result['id']; // 성공 결과 값에서 생성된 key의 id를 가져옴 // 사용량계획 연결 $result = $apiGatewayClient->createUsagePlanKey([ 'keyId' => $apiKeyId, // 위에서 생성한 키 id 'usagePlanId' => 'plan id hear', // 미리 만들어 놓은 사용량 계획 ID 'keyType' => 'API_KEY' ]); 키 삭제 키 생성시 DB에 별도 저장한 키 id로 삭제를 수행한다. use Aws\Credentials\Credentials; use Aws\Signature\SignatureV4; use Aws\ApiGateway\ApiGatewayClient; // signature 생성 $accessKey = 'access key'; $secretKey = 'srcret key'; // AWS 자격 증명 및 API Gateway 클라이언트 설정 $credentials = new Credentials($accessKey, $secretKey); $apiGatewayClient = new ApiGatewayClient([ 'region' => 'ap-northeast-2', 'version' => 'latest', 'credentials' => $credentials, 'signature' => new SignatureV4('apigateway', 'ap-northeast-2') // region 설정 ]); // 삭제할 API 키의 ID $apiKeyIdToDelete = 'DB에 별도 보관한 키 ID 입력'; // API 키 삭제 $apiGatewayClient->deleteApiKey([ 'apiKey' => $apiKeyIdToDelete, ]);
-
[jQuery] Lazy 로 이미지 리소스 트래픽 절약하기
이미지가 리소스가 많은 웹페이지 로드시 과도한 트래픽이 발생하게 되는데, lazy 는 화면에 노출된 이미지 리소스를 그때그때 로드하여 출력해 주는 플러그인이다. Plugin include cdn 서비스나 본 글 하단에 첨부된 js파일을 다운로드 하여 lazy 적용을 원하는 웹페이지 상단에 인클루드 한다. <script type="text/javascript" src="jquery.lazy.min.js"></script> img 태그 수정 lazy가 적용될 <img> 요소를 아래와 같이 수정한 다음, plugin 을 적용한다. <HTML> 1. src 어트리뷰트를 data-src 로 변경 2. class="lazy" 추가 <img data-src="path/to/image.jpg" class="lazy" /> <jQuery> .lazy 가 부여된 이미지 리소스에 대해 lazy 적용 $(function() { $('.lazy').Lazy(); }); 상세 옵션 설정 lazy는 커스터마이징이나 디버깅 할 수 있는 몇가지의 옵션을 제공한다. ( 전체 옵션 확인 : http://jquery.eisbehr.de/lazy/#configuration ) $(function() { $('.lazy').Lazy({ 'thresold' : 100, // 이미지가 화면에 100px 만큼 보인 시점에 등장하도록 설정 'effect' : 'fadeIn', // fade 등장효과 적용 (기본값: show) 'effectTime' : 500, // fade 적용시 duration 시간 'onError' : function(element) { // img 로드 실패시 callback 함수 console.log('error loading ' + element.data('src')); } }); });
-
[CSS] backdrop-filter 로 겹침 효과 주기
한때 음악 어플의 앨범 커버이미지 ui에서 자주 볼 수 있었던 흐림 효과를 CSS로 구현할 수 있다. backdrop-filter 를 통해 구현할 수 있는데, IE가 지원 중단 되면서 부터 비교적 자유롭게 사용할 수 있게 되었다. 사용법은 아래와 같다. blur backdrop-filter 중에 내가 가장 자주 사용하는 속성은 blur. backdrop-filter: blur(10px); 위와 같이 적용해 주면 되는데, 다만, 부모 엘리먼트에 이미 backgrop-filter 가 적용되어 있다면, 자식 요소에서는 적용되지 않는다는 점을 주의하자. invert / sepia등 다양한 속성 제공되는 다양한 속성 중 inver와 sepia를 비롯해 다양한 속성을 제공한다. 예시는 아래와 같다. backdrop-filter: invert(80%); backdrop-filter: sepia(90%); 아래는 Mozilla 가이드 페이지에서 제공하는 속성 설명이다.
-
AWS S3 리소스에 대한 CORS(크로스도메인) 설정 방법
S3에 저장된 이미지 리소스를 외부 사이트 웹페이지 등에서 사용 할 때 웹페이지의 도메인과 S3 endpoint의 도메인이 달라 크로스도메인(CORS) 오류가 발생하여 리소스가 로드되지 않는 경우 S3 콘솔에서 CORS 를 설정하여 특정 도메인의 크로스도메인 접근을 허용할 수 있다. AWS S3 버킷 관리 콘솔 AWS - S3 - 버킷 선택 - 권한 - CORS(Cross-origin 리소스 공유) 로 이동하여 [편집] 버튼을 클릭하여 관리 팝업을 연 다음 아래와 같 이 입력한다. CORS 설정 (JSON) AWS S3 에서는 JSON으로 CORS 설정이 가능하여 아래 구문을 복사한 뒤 적절히 수정하여 적용한다. [ { "AllowedHeaders": [ "*" ], "AllowedMethods": [ "GET", "PUT", "POST", "DELETE" ], "AllowedOrigins": [ "https://허용할도메인1.com", "http://허용할도메인2.com" ], "ExposeHeaders": [] } ] CORS 설정 (XML) 대부분의 Object Storage 서비스는 S3 CORS 설정 방법과 동일하나, XML 구문만 지원하는 서비스도 간혹 있는데, XML의 경우 아래와 같이 설정한다. <CORSConfiguration> <CORSRule> <AllowedOrigin>https://허용할도메인1.com</AllowedOrigin> <AllowedMethod>PUT</AllowedMethod> <AllowedMethod>POST</AllowedMethod> <AllowedMethod>DELETE</AllowedMethod> <AllowedHeader>*</AllowedHeader> </CORSRule> <CORSRule> <AllowedOrigin>http://허용할도메인2.com</AllowedOrigin> <AllowedMethod>PUT</AllowedMethod> <AllowedMethod>POST</AllowedMethod> <AllowedMethod>DELETE</AllowedMethod> <AllowedHeader>*</AllowedHeader> </CORSRule> <CORSRule> <AllowedOrigin>*</AllowedOrigin> <AllowedMethod>GET</AllowedMethod> </CORSRule> </CORSConfiguration>
-
[HTML] textarea placeholder 에서 줄바꿈하기 1
textarea 에서 placeholder 입력시 \n 혹은 \r\n 로 줄바꿈을 할 수 없는데, 아래와 같이 엔터티를 입력하여 줄바꿈 가능하다. <textarea placeholder="첫 번째 줄 두 번째 줄"></textarea> 줄바꿈 엔터티 : 아래는 줄바꿈 placeholder 가 적용된 textarea.
-
[CSS] CSS만으로 scrollbar 디자인하기
최근 익스플로러가 사용 중단 조치 되면서 스크롤바 디자인이 좀 더 자유로워졌다. 아래 CSS를 통해 간단히 웹킷 브라우저에서 스크롤바 디자인을 변경할 수 있다. CSS 아래 코드를 통해 스크롤바 디자인이 가능하다. .scroll::-webkit-scrollbar {width: 10px} .scroll::-webkit-scrollbar-thumb {background-color: #b4b4b4; border-radius: 10px; background-clip: padding-box} .scroll::-webkit-scrollbar-track {background-color: #f1f1f1; border-radius: 10px; } 위 코드에서 .scroll 은 스크롤이 적용되는 엘리먼트이며, ::-webkit-scrollbar 는 스크롤바 전체 영역, ::-webkit-scrollbar-thumb 는 스크롤 바, ::-webkit-scrollbar-track 는 트랙의 스타일을 지정하면 된다. 예시는 아래와 같다.
-
[jQuery] jQuery UI autocomplete 적용하기
jQuery UI에 기본 탑재된 자동완성 기능 (autocomplete) 샘플 코드. 배열을 미리 선언하여 사용하는 방법과 ajax 방식으로 배열을 가져와 구동하는 방법으로 사용할 수 있는데 아래 예시는 배열을 미리 선언한 뒤 사용하는 방식이다. 자동완성 배열 선언 searchSource = [ { 'label' : '서울', 'value' : 'seoul' }. { 'label' : '대전', 'value' : 'daejun' } ] 자동완성 적용 위에서 선언된 배열을 자동완성으로 적용하는 예제이며, 자동완성을 선택하는 경우 위 배열 중 'value'는 input의 value가 되며, 'label'은 자동완성에서 노출될 항목명이 된다. <HTML> <input type="text" name="address" autocomplete="off"> <jQuery> $('input[name="address"]').autocomplete({ 'source' : searchSource, // 위에서 선언한 배열 'minLength' : 0, // 최소 몇글자 입력시 자농완성 노출할 것인지 'autoFocus' : false, // 자동으로 첫번째 항목에 focus를 위치시킬 것인지 'position' : { my : 'right top', at : 'right bottom' }, // 자동완성 창의 노출 위치 'delay' : 0, // 노출 딜레이 시간 'z-index' : 999, // z-index 'classes' : {}, // 자동완성 기본 css class 를 custom class로 대입하는 옵션. 'select' : function(event, ui) {}, // 항목 선택시 수행할 작업 'focus' : function(event, ui) {}, // 항목 focus시 수행할 작업 'close' : function(event) {} // 닫는 경우 수행할 작업 }).on({ 'focus' : function() { $(this).autocomplete("search", ""); // input에 포커싱 되는 순간 자동완성이 열리게 하는 코드 } }); autocomplete가 적용된 ui는 아래 예시와 같다.
-
[PHP] 배경색(HEX 코드) 판별하여 적합한 글자색(흰색/검정색) 반환
Element에 배경색과 배경색 위에 얹혀질 글자 색을 지정하는 경우 배경색이 밝은지 어두운지 판별하여 횐색/검정 글자중 적합한 색을 반환해 주는 함수. 코드에 HEX코드를 넣어주면 결과 값으로 black 혹은 white를 반환해준다. 배경색에 따라 white / black 반환 아래와 같이 함수에 HEX값 (배경색)을 넣어주면 white / black을 반환해 준다. // 글자색 반환 함수 function get_text_color($hex) { $rgb = sscanf($hex, "#%2x%2x%2x"); $brightness = (($rgb[0] * 299) + ($rgb[1] * 587) + ($rgb[2] * 114)) / 1000; return ($brightness > 125) ? 'black' : 'white'; } // 글자색 반환 실행 get_text_color('#000000'); // 결과 값 : 'white' 반환 위 함수는 아래와 같이 활용할 수 있다.
-
[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
-
[centOS] CentOS 7 에서 기본적인 iptables 설정 방법
centos7은 firewalld와 iptable이 함께 구동 되는데, 나의 경우 firewalld가 익숙하지 않기 때문에 firewalld를 비활성화 한 뒤 iptable 위주로 사용한다. 서버 앞단에 방화벽이 없는 경우 iptable 설정이 필수이기 때문에 기본적인 설정 방법을 정리해 본다. firewalld 사용을 원치 않는 경우 비활성화 하기 아래 명령어로 firewalld를 종료 및 비활성화 한다. # systemctl stop firewalld # systemctl mask firewalld iptables-services 설치 iptable-services 가 설치되어 있지 않은 경우 iptables 데몬 시작시 'Failed to start iptables.service: Unit not found.'와 같은 에러가 발생한다. 아래와 같이 iptables-services 를 설치한다. #yum install iptables-services iptables 정책 확인 아래와 같이 현재 설정되어 있는 iptable 정책 내용을 확인한다. # iptables -nL 모든 포트 접속을 차단한 뒤 특정 포트만 접속 허용 보안을 위해 서버에 들어오는 모든 포트를 기본적으로 차단하고 특정 필요한 포트만 개방시키는 정책을 설정한다. 먼저 설정되는 정책이 우선 순위를 갖게 되므로 허용할 포트를 먼저 설정한 뒤 모든 포트를 차단하는 정책을 마지막에 설정해야 한다. 차단 정책이 먼저 설정되는 경우 SSH 접속이 불가하니 주의해야 한다. 가장 먼저, 현재 등록되어 있는 정책을 모두 초기화 시킨다. # iptables -F output tcp/udp 포트는 모두 개방시킨다. # iptables -A OUTPUT -p tcp -j ACCEPT # iptables -A OUTPUT -p udp -j ACCEPT 한번 연결된 트래픽에 대한 응답을 지속 시키기 위해 아래와 같이 정책을 추가한다. 아래 정책이 없는 경우 pdo로 database를 연결하는 웹앱에서 문제가 발생할 수 있다. # iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT 그 다음, 필요한 포트를 아래와 같이 개방 시킨다. # iptables -A INPUT -p tcp --dport 22 -j ACCEPT 아래와 같이 범위로 포트를 지정할 수도 있다. # iptables -A INPUT -p tcp --match multiport --dports 5000:5050 -j ACCEPT 필요 포트를 모두 개방 하였다면, 마지막으로 나머지 포트를 모두 차단한다. # iptables -A INPUT -j DROP 등록된 정책의 우선순위 변경 아래와 같이 나중에 등록한 정책의 우선순위를 높일 수 있다. 원하는 우선순위를 숫자로 입력하여 설정한다. # iptables -I INPUT 1 -p tcp --dport 8080 -j ACCEPT 등록된 정책 삭제 등록된 정책 중 원치않는 정책을 삭제할 수 있다. 우선순위의 숫자로 지정 하거나, 포트 번호를 명시하여 지정할 수 있다. # iptables -D INPUT 1 # iptables -D INPUT -p tcp --dport 8080 -j ACCEPT 정책 저장 및 복구 iptable 사용시 주의해야 할 점은, 데몬을 restart하는 경우 정책이 모두 초기화 된다는 점이다. (이를 보완하기 위한 데몬이 존재하기는 하지만) 지금까지 설정한 정책을 시스템에 저장한 뒤 원할 때 마다 복구시킬 수 있는 방법이 있다. 먼저, iptable 정책 설정이 마무리 되었다면 아래와 같이 정책을 저장한다. # service iptables save or # iptables-save > /etc/sysconfig/iptables 데몬 재시작 후 정책이 초기화 되었다면 아래와 같이 저장된 정책을 다시 복구시킨다. # iptables-restore < /etc/sysconfig/iptables iptable을 통해 접속 ip 차단 시키기 iptable에서 특정 input ip를 접속 차단시킬 수 있는데, 정책 등록시 아이피 대역으로도 설정할 수 있다. 아래와 같이 ip를 지정하여 접속을 차단시킨다. (이때 아이피 차단을 가장 우선순위로 하기 위해 숫자 1을 함께 지정한다.) # iptables -A INPUT 1 -s 111.222.333.444 -j DROP [ ip대역으로 차단하는 경우 - 111.222.333.xxx ] # iptables -A INPUT 1 -s 111.222.333.0/24 -j DROP [ ip대역으로 차단하는 경우 - 111.222.xxx.xxx ] # iptables -A INPUT 1 -s 111.222.0.0/16 -j DROP [ ip대역으로 차단하는 경우 - 111.xxx.xxx.xxx ] # iptables -A INPUT 1 -s 111.0.0.0/8 -j DROP vi 로 iptable 관리하기 앞서 명령어를 통한 iptable 설정방법 외에도 아래와 같이 vi 로도 설정할 수 있다. iptable에 등록된 정보가 많은 경우 vi를 통해 손쉽게 관리 가능하다. # vi /etc/sysconfig/iptables
-
[PHP] sms 본문 내용 byte 계산 (멀티바이트로 계산하기 - 한글 2byte)
SMS의 내용을 byte로 계산할 때 일반적으로 한글, 특수문자는 2byte, 영어, 숫자 줄바꿈등은 1byte로 계산한다. 한글을 php나, javascript에서 UTF-8의 byte를 계산하는 경우 3byte로 계산하는데, sms 서비스의 경우 한글을 2byte로 계산해야 한다. mb_strwidth() 함수를 사용한 byte 계산 아래와 같이 멀티바이트 (string width)로 계산하면 한글을 2byte로 계산할 수 있다. function getByteLength($str) { $strlen = mb_strwidth(str_replace("\r\n", "\n", $str), 'UTF-8'); return $strlen; } 위 코드 중 str_replace("\r\n", "\n", $str) 코드는 리눅스의 경우 줄바꿈을 \r\n 으로 처리하기 때문에 2byte가 되는데, 이를 윈도우 기준인 \n으로 치환하여 1byte로 계산 하도록 한다.
-
[Javascript] SMS 본문 내용 byte 수 계산하는 함수
SMS문자 본문 내용의 byte를 계산하는 간단한 코드. ASCII 코드가 128이상인 경우(한글, 한문, 특수기호 등) 2byte로 계산하고 그 외의 문자 (영어, 숫자, 기본기호 등)는 1byte로 계산한다. Javascript // 내용 byte 체크 function getByteLength(str) { var byteLen = 0; for(var i = 0; i < str.length; i++) { var charCode = str.charCodeAt(i); if (charCode > 128) { byteLen += 2; } else { byteLen ++; } } return byteLen; }
-
[jQuery] 마우스 드래그 금지 & 우클릭 금지
마우스 드래그 및 우클릭 금지하는 jquery 코드. event로 간단하게 처리 가능하다. jQuery <script type="text/javascript"> $(document).ready(function(){ //우클릭 금지 $(document).bind('contextmenu', function(e){ return false; }); //드래그 금지 $('*').bind('selectstart', function(e){ return false; }); }); </script>
-
[PHP] microtime과 랜덤 문자를 조합하여 중복되지 않는 PK 문자 만들기
microtime() 과 랜덤 글자 조합하여 중복되지 않는 Primary Key 문자를 생성하는 함수. 함수의 인자 값으로 원하는 길이를 넘기면 랜덤 문자열과 microtime()을 조합 후, 다시 str_shuffle()로 무작위로 섞은 결과 문자열을 return 해준다. ($length는 최소 30자 이상 설정 가능) Primary Key 생성 함수 function make_random_char($length = 30) { $length = ($length < 30) ? 30 : $length; $length = $length - 19; $characters = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'; $randomString = ''; $max = strlen($characters) - 1; for ($i = 0; $i < $length; $i++) { $randomString .= $characters[mt_rand(0, $max)]; } $microtime = str_replace(array(' ', '.'), array('', ''), microtime()); return str_shuffle($randomString.$microtime); // 문자열을 다시 무작위로 섞음 } 결과 예시 4q344nM250001GS69e2y2X61198mT1
-
[PHP] 연락처가 올바른 연락처인지 검증하는 함수
연락처가 올바른 연락처인지 검증하는 함수. 함수에 연락처를 인자로 전달할 때 하이픈(-)을 포함하여야 한다. - 000-000-0000 (휴대전화번호) - 000-0000-0000 (휴대전화번호) - 00-000-0000 (유선전화번호) - 00-0000-0000 (유선전화번호) - 000-000-0000 (유선전화번호) - 000-0000-0000 (유선전화번호) - 0000-0000 (대표전화번호) <?php function get_phone_check($number) { if (!preg_match('/^[0-9-]/', $number)) return false; if (!preg_match('/^0(2|[3-9]\d{1})-?\d{3,4}-?\d{4}$|^01([016789])-?\d{3,4}-?\d{4}|\d{4}-\d{4}$/', $number)) return false; return true; } ?>