DevNote

Recent Posts

[MacOS, Firebase] iOS Firebase 앱푸시를 위한 APN 인증서 생성 방법 Firebase 를 통해 iOS 앱푸시를 이용 중인데, 24년도 이전에 제작한 iOS앱의 경우 Firebase에 p12 방식의 인증서가 등록되어 있다. p12 인증서의 경우 만료일이 1년으로 설정되어 있기 때문에 애플 개발자센터에서 발급 받은 APN 인증서를 Firebase 에 재등록해야 한다. 또한, APN발급을 위해서는 자체서명인증서(csr) 이 사전에 준비되어 있어야 하는데, 자체서명 인증서는 MacOS 또는 리눅스에서 가능하다. (openssl 사용을 위해) 자체서명 인증서 생성(csr) - Mac or Linux에서 가능 MacOS 또는 리눅스 운영체계에서 '터미널'을 연다음 아래와 같이 자체서명 인증서를 생성한다. 2048비트 RSA 개인 키 생성 openssl genrsa -out mykey.key 2048 CSR 생성 openssl req -new -key mykey.key -out mycsr.csr 주의할 점은, 아래와 같이 정보를 정확하게 입력해야 인증서 유효성 검증에 성공한다. - Country Name : KR - State or Province Name : Seoul - Locality Name : Seoul - Organization Name : 조직명 - Organizational Unit Name : 조직명 - Common Name : 앱 Bundle ID (ex: AAAAAABBBBB.com.CCCC.App) APNs(cer) 발급 (애플 개발자센터) 애플 개발자센터로 이동하여 아래와 같이 자체서명인증서 첨부 및 APN 인증서를 발급받아 다운로드 받는다. 1. 로그인 -> Account -> 인증서, 식별자 및 프로파일 상단 Certificatese 우측 [+] 버튼 클릭하여 인증서 생성 화면으로 이동 2. Apple Push Notification service SSL (Sandbox & Production) 선택 후 Continue 클릭하여 다음 화면으로 이동 3. 인증서 발급 하려는 App ID 선택후 Continue 클릭 4. Choose File 선택하여 위에서 생성한 mycert.csr 파일 첨부 5. Download 버튼 클릭하여 aps.cer 다운로드 p12인증서로 변환 애플에서 다운받은 aps.cer 파일을 pem 파일로 변환 openssl x509 -in aps.cer -inform DER -out aps.pem -outform PEM 개인 키(key, pem) 과 함께 .p12 파일을 생성 openssl pkcs12 -export -inkey mykey.key -in aps.pem -out aps.p12 - Enter Export Password : 패스워드 설정후 기억할 것! Firebase 인증서 추가 위에서 생성한 aps.cer 또는 p12 인증서를 Firebase -> setting -> 프로젝트설정 -> 클라우드메시징 으로 이동하여 업로드 및 위에서 p12 생성시 설정한 패스워드를 입력하여 등록 완료.
[jQuery] .animate() 로 숫자 카운팅 구현하기 숫자 0부터 숫자가 커지는 카운팅 효과를 구현해본다. 구현된 결과 화면 예시 HTML 카운팅될 엘리먼트를 추가한다. <ul> <li> <div class="no">+<strong>1300</strong></div> <p>일반 참가자</p> </li> <li> <div class="no">+<strong>520</strong></div> <p>참가기업</p> </li> <li> <div class="no">+<strong>230</strong></div> <p>비즈매칭 참가기업</p> </li> <li> <div class="no">+<strong>220</strong></div> <p>비즈매칭 수</p> </li> <li> <div class="no">+<strong>80</strong></div> <p>전시 참가 기업</p> </li> <li> <div class="no">+<strong>30</strong></div> <p>IR 참가 기업</p> </li> </ul> jQuery 아래와 같이 코드를 적용한다. 해당 객체에 Counter atteibute를 추가하여 값을 0으로 설정한 뒤 animate로 증가시키는 방법이다. $(this).prop('Counter', 0).animate({ Counter: $(this).text()}, { duration: 3000, easing: 'swing', step: function (now){ // $(this).text(Math.ceil(now)); // 콤마 없는 숫자 노출 원하는 경우 $(this).text(Math.ceil(now).toLocaleString()); // 콤마 처리된 숫자 노출 원하는 경우 } });
nginx에서 http->https 리디렉션 설정된 경우 let's encrypt 인증서 갱신 안될때 nginx 를 사용할 때 특정 조건에서 let's encrypt 인증서가 갱신이 안되는 경우가 있다. 나의 경우 http 접속하는 경우 https로 리디렉션 함과 동시에, proxy 를 통해 목적지 서버로 트래픽을 전달하는데, 이 과정에서 webroot를 찾지 못해 갱신이 안되는 문제였다. 따라서, 아래와 같이 certbot에서 웹서버를 접근하는 경우 https로 리디렉션 되지 않도록 예외 처리 하였다. 기존 문제가 된 구문 server { listen 80; server_name note.chanyeongpark.com; index index.html; root /서버경로/; return 301 https://note.chanyeongpark.com$request_uri; // 문제가 되는 구문 } 301로 https로 리디렉션 되고 있는 구문을 아래와 같이 수정하였다. 수정된 구문 아래와 같이 certbot에서 접근하는 경우 예외처리하여 https로 리디렉션 되지 않도록 처리하였고 정상 갱신 되는 것을 확인 하였다. server { listen 80; server_name note.chanyeongpark.com; index index.html; location /.well-known/acme-challenge/ { root /서버경로/; } location / { return 301 https://note.chanyeongpark.com$request_uri; } }
[PHP] 에디터로 작성한 HTML 코드 중 <img> 와 <img> 사이에 <br> 태그 두개 넣기. 본인이 운영하는 블로그는 다수의 사진이 입력되는 게시글이 많다. 오랜 기간 블로그 글을 작성하다 보니, 게시글 마다 사진과 사진 사이 여백이 제각각이다. 에디터로 작성된 html코드 중에서 정규식을 통해 <img> 와 <img> 태그 사이를 찾아 <br> 태그가 없거나, 2개 미만 이거나, 2개를 초과하는 경우 무조건 <br> 두개가 삽입 되도록 코드를 변경하여 출력해 줬다. <img>와 <img>를 찾아 적용 모든 <img>와 <img> 사이를 찾아 <br> 두개를 입력해 준다. // 정규식으로 각 <img> 태그 사이에서 <br>을 최대 2개만 남기기 (없거나 2개 미만일 때도 2개로 맞춤) $pattern = '/(<img[^>]*>)(\s*(<br\s*\/?>\s*)*)/i'; $replacement = '$1<br><br>'; $result = preg_replace($pattern, $replacement, $html); echo $result; <img class="lazy">와 <img class="lazy"> 사이만 찾아 적용 img 태그에 class="lazy" 와 같이 특정한 조건에 부합하는 경우에만 적용한다. // 정규식으로 class="lazy"가 있는 <img> 태그에만 적용 $pattern = '/(<img[^>]*class="lazy"[^>]*>)(\s*(<br\s*\/?>\s*)*)/i'; $replacement = '$1<br><br>'; $result = preg_replace($pattern, $replacement, $html); echo $result;
[HTML] text input에 입력 허용할 문자 지정하기 (inputmode, pattern Attribute) 이를테면, <input type="number"> 로 지정하는 경우 오로지 숫자만 입력 가능하여 하이픈(-) 입력이 불가 하다는 문제점이 있다. 대안으로 아래와 같이 input type을 text로 두고 정규식으로 허용할 문자를 지정할 수 있다. text input에서 inputmode, pattern 지정 <input type="text" inputmode="numeric" pattern="[0-9\-]*" placeholder="숫자와 하이픈 입력 가능">
[Javascript] ios 사파리에서 CSS 100vh 높이가 제대로 적용되지 않을 때 ios 사파리의 경우 100vh 높이가 더 크게 표현되는 오류가 있다. 실제 브라우저 height 만큼 100vh가 인식되도록 하기 위해 javascript로 css 변수를 만들어주면 제대로 표현 가능하다. javascript로 100vh 변수 생성하기 CSS에서 사용할 수 있도록 브라우저 높이를 계산하여 변수로 전달한다. // ios 에서 100vh 계산 위한 변수 생성 function setDynamicHeight() { let vh = window.innerHeight * 0.01; document.documentElement.style.setProperty('--vh', `${vh}px`); } // 초기 실행 및 창 크기 변경 시 업데이트 setDynamicHeight(); window.addEventListener('resize', setDynamicHeight); CSS 에서 변수 사용하여 100vh 표현하기 아래와 같이 javscript로 만든 --vh 를 활용할 수 있다. max-height: calc(var(--vh, 1vh) * 100 - 170px);
[jQuery] datepicker 로 check in/out 구현하기 여행, 예약사이트에서 흔히 볼 수 있는 check in/out 을 jQuery UI의 Datepicker로 구현하는 방법을 안내한다. input 두개를 만들어 각각 datepicker 가 트리거 되도록 하여 구현한다. HTML check in 과 out input 두개를 만든다. <input type="text" datepicker checkin> <input type="text" datepicker checkout> jQuery 각 input에 대해 아래와 같은 옵션으로 datepicker 를 적용한다. // check in/out let datepicker_checkin = $('input[datepicker][checkin]').datepicker({ dateFormat: 'yy-mm-dd', minDate: 0, onSelect: function(selectedDate) { let $this = $(this); let date = $(this).datepicker('getDate'); date.setDate(date.getDate()); // 당일치기도 가능한 경우 // date.setDate(date.getDate() + 1); // 무조건 1박 이상 가능한 경우 datepicker_checkout.datepicker("option", "minDate", date); // check in 날짜 선택하는 경우 자동으로 check out Datepicker를 띄움 setTimeout(function() { $this.parent().find('input[datepicker][checkout]').datepicker('show'); }, 10); } }); let datepicker_checkout = $('input[datepicker][checkout]').datepicker({ dateFormat: "yy-mm-dd", minDate: 1 });
[MacOS] 터미널에서 tar 압축시 숨김파일 압축되지 않도록 하기 MacOS에서 '터미널' 앱으로 특정 경로의 폴더/파일을 압축한 다음, 압축 파일을 리눅스 등 다른 OS로 가져가 압축을 해제하는 경우 ._파일명 과 같은 숨김파일이 함께 생성된다. 이는, 맥OS에서 원본 파일에 대한 리소스포크와 메타데이터 기록을 위한 숨김 파일로 맥OS에서는 파일이 보이지 않으나, 타 OS로 폴더를 이동하는 경우 비로소 보이게 된다. 맥OS 에서 터미널 앱을 통해 tar 로 압축을 진행할 때 아래와 같은 명령어로 숨김파일이 함께 압축되지 않도록 해야한다. 숨김파일이 압축되지 않도록 하기 #COPYFILE_DISABLE=1 tar --exclude='._*' --exclude='.DS_Store' -zcvf 압축할파일명.tar.gz 압축할 경로 위와 같이 COPYFILE_DISABLE=1 로 메타데이터가 생성되지 않도록 환경변수 값을 변경한 다음 --exclude='._*' 로 '._' 로 시작하는 숨김파일을 제외하고 압축시킨다.
[윈도우서버] 최대 동접자수를 늘리기 위한 윈도우 서버 설정 윈도우에서 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
홈서버 구축기 / 보안을 염두한 홈서버 네트워크 구성 이사를 계획하게 되면서 새로운 집에서 홈서버 네트워크 구축을 해보자 맘을 먹었고 이사한지 한달도 채 되지 않아 IDC에서 운영중이던 서버를 반출하고 홈서버를 구축했습니다. 몇년전에도 홈서버를 구축했던 적이 있는데, 애매한 장비들로 구축하는 바람에 어설프게 끝나고 말았던 경험이 있습니다. 다시는 IDC 입주를 하지 않겠다는 굳은 각오로 홈서버 네트워크를 구축하게 되었으며, 고생 끝에 완성된 저만의 홈서버 네트워크를 기록으로 남겨 봅니다. 1 홈서버 구축을 결심하게 된 이유 첫째, IDC 비용이 부담으로 다가왔습니다. 네임서버 2대, 웹서버 1대, 스토리지 서버 1대를 운영 중이었는데, 최근 이사를 하면서 큰 지출을 하게 되니 매달 지출되는 서버 비용이 아깝다 느껴졌습니다. 네임서버 2대를 AWS Route53으로 전환하고, 스토리지 서버를 시놀로지 나스로, 1U 웹서버를 데스크탑으로 타협하여 IDC 비용을 줄여보자는 계산이었습니다. 무엇보다 우리 집은 같은 방이라도 랜포트별로 개별 아이피가 들어오기 때문에 가성비 좋은 홈서버 구축이 가능한 상황이었습니다. (랜포트 마다 아이피가 다른건 처음이라 놀라웠습니다. 신축 아파트는 다 그런가요..?) 둘째, 서버를 소비하는 느낌이 싫었습니다. 제가 운영하는 웹사이트는 손수 디자인하고, 개발하여 제작하는 반면, 서버는 비싸게 구입하게 되지만, IDC로 직행하여 수명을 다할 때 쯤 되어서야 제 눈으로 볼 수 있다는게 매번 아쉬움으로 남았습니다. 랜선도 직접 꽂아주고, 장애가 생기면 십자 드라이버로 직접 분해하여 고쳐주는등 애착을 갖고 정성을 다해 관리해보고 싶었습니다. 2 네트워크 구성 홈서버 네트워크에 트래픽이 유입되는 경우 [클라이언트] => [외부 프록시 서버] => [공유기] => [프록시서버] => [웹서버 / 스토리지서버] 순으로 흐르게 됩니다. 각 장비별로 정리해 보았습니다. 1) 공유기(라우팅) 아이피타임의 가정용 인터넷 공유기 관리콘솔이 친숙하다는 이유로 아이피타임의 랙용 유선 공유기를 설치 하였습니다. 외부에서 트래픽이 아이피타임 공유기로 들어오게 되면 80/443 포트로 들어온 경우 프록시 서버로, 그외 포트는 해당하는 서버로 포트 포워딩 합니다. 추후 서버 증설을 염두하여 랜포트가 많은 모델을 찾다가 이 제품으로 선택했습니다. 모델명 : IPTIME T16000M 구성 : port기반 포워딩 금액 : 신품 18만원 2) 리버스프록시 서버 중계 서버란 이유로 가장 저가형으로 당근에서 15만원에 매수한 intel N100 CPU의 미니PC입니다. 중국제 미니 PC에서 흔히 볼 수 있는 저가형 CPU로 내부 프록시 역할만 할 것이므로 사양을 최대한 타협하여 지출을 아꼈습니다. 사용하다 성능이 부족하다 싶으면 업그레이드 할 생각입니다. nginx 를 통해 공유기로 부터 전달된 트래픽을 도메인 기반으로 Reverse proxy 하여 웹서버 혹은 시놀로지 NAS로 전달합니다. 사양 : CPU - intel N100 (4Core 4Threds) / RAM - ddr4 16G 구성 : nginx + reverse proxy 금액 : 중고 15만원 3) 웹서버 구입시 가장 고민이 많았던 서버였습니다. 과연 나에게 ecc 램이 필요할까란 생각에 며칠을 깊은 고민에 빠졌지만, 결과는 '필요 없음' 이었습니다. 장애가 생겨 사이트 접속이 단절 된다는 가정을 해봤고, 회원들이 용인해줄 수 있는 단절 시간은 몇분 정도일까 생각 해봤는데 결과는 '하루' 였거든요...ㅎ 당근에서 좋은 가격으로 intel CPU기반의 데스크탑으로 들여왔습니다. ('이그닉'이라고 아시나요?) CPU가 ecc 지원 모델이라 내심 기대하고 본체를 뜯어보니 메인보드가 ecc 를 non-ecc로 작동 시키는 보드네요. ㅎㅎ 당근에서 가져온 데스크탑을 다시 분해하여 랙에 맞는 3U 케이스와 파워서플라이를 구매하여 재조립 하였습니다. window OS 위에 VMWare를 얹어 centos + apache + mariadb 조합으로 운영되는 웹서버입니다. 이 데스크탑을 구매하기 전, IDC에서 반출한 1U를 집에서 반나절 돌렸다가 와이프에게 등짝 스매싱을 당하고 바로 처분 했습니다. 사양 : CPU- intel i7 12700 (12Core 20Threds) / RAM - ddr4 32G 구성 : window10 + VMWare VPS(centos + mariadb + apache) 당근에서 구입하여 적출하여 재조립한 구성은 아래와 같습니다. 적출당한 미니데스크탑(M-ATX 플랫폼 보드) 금액 : 신품 중고거래 60만원 소음과 효과적인 방열을 위해 3U케이스를 선택 했습니다. 적출한 부품을 재조립 하기 위한 3U케이스 구매 모델명 : AMAQUEST K338F 3U / 금액 : 약 8만원 애초 구매한 데스크탑과 3U 케이스의 파워서플라이 규격이 달랐기에, 케이스 규격에 맞는 파워서플라이를 추가 구매 하였습니다. 추후 하드디스크 추가 장착을 고려하여 정격출력 350W 에서 500W로 조금더 큰 것으로 구매 하였습니다. 3U 케이스 규격에 맞는 파워서플라이 추가 구매 모델명 : 쿨러마스터 MWE 500 BRONZE V2 230V / 금액 : 약 5만원 4) 스토리지서버/메일서버/백업서버 (시놀로지 나스) 시놀로지 나스는 DS1621+ 6bay 모델입니다. 홈 네트워크에서 가장 많은 일을 하는 바쁜 서버입니다. 역할에 비해 부족한 하드웨어 사양으로 인해 시놀로지가 수명을 다하면 헤놀로지로 도전해볼까 진지하게 고민중입니다. 아래는 시놀로지가 하는 일입니다. 참 바쁘죠..? [스토리지 서버] docker + minio 조합으로 Object Storage 서버를 구동하여 웹서버에서 업로드되는 모든 리소스는 시놀로지 나스 도커로 들어가게 됩니다. 웹서버와 시놀로지간 통신은 AWS S3 SDK 를 활용하고 있습니다. [메일서버] 웹서버의 메일서버로 활용되고 있습니다. 메일 수신은 시놀로지 MailPlus Server 가 직접 담당하고 있으며, 메일 송신은 AWS SES SMTP 를 relay 하여 발송하고 있습니다. [원격 백업 서버] 웹서버, 프록시서버, 외부 프록시서버에서 매일 새벽3시에 시놀로지로 원격 백업을 수행합니다. [개발서버 활용] docker에 다양한 개발 환경을 구축해 두고 개발용 서버로 활용합니다. 모델명 : DS1621+ 구성 : docker를 통한 minio 파일 서버 + 메일서버 + 원격백업서버 사양 : CPU - AMD Ryzen V1500B (4Core 8Threds) / RAM - ddr4 16G / hdd : 18T 금액 : 하드 미포함 160만원 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이지 않아도 되는 하드웨어 구성의 자유로움, 적은 비용으로 서버 공부 할 수 있다는 점, 서버에 애착을 가질 수 있다는점.. 그리고, 방안에 크고 못생기고 시끄러운 서버랙을 볼 때 마다 이런 짓을 이해해주고 응원해주는 우리 재무부장관님께 감사함을 느낄 수 있다는 것은 큰 장점입니다. 장관님 감사합니다. 2024년 7월 현재는 관리가 용이하도록 WEB서버의 VM으로 내부 프록시서버가 통합 되었으며, 시놀로지 나스는 DS1621+ 에서 RS1221+로 기변되었으며, WEB서버는 하드웨어가 상당부분 업그레이드 되었습니다. 또한, 방음을 위해 전체 하드웨어의 쿨러가 녹투아 쿨러로 교체 되었습니다. 2024년 10월 현재는 메인 웹서버가 하드디스크 핫스왑, 쿨링 개선을 위해 케이스가 silverstone rm400 으로 교체 되면서 일부 장치가 추가 되었습니다. .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] 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 에러가 리턴되는 것을 확인할 수 있다.
[시놀로지] 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 되는 10M만 소진하면 된다. 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 epel-release # 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&region=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 에서 줄바꿈하기 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}'