끄적 끄적 로깅! 로깅!

[linux] cron.d 설정으로 haproxy 로그 logrotate 적용

warpmemory — Fri, 20 Oct 2023 17:12:59 +0900

1분 주기로 haproxy 로그 확인해서 100M 넘으면 로테이트해서 500개 까지 보관(crontab 사용하지 않고, /etc/cron.d 설정)

mkdir /etc/logrotate.hourly

cat <<EOF > /etc/logrotate.hourly/haproxy
/var/log/haproxy/haproxy.log
/var/log/haproxy/haproxy-*.log {
  hourly
  missingok
  nocompress
  notifempty
  size 100M
  rotate 500
  dateext
  dateformat -%Y%m%d%H-%s
  #copytruncate
  postrotate
    /usr/bin/pgrep rsyslogd | xargs -I{} kill -s HUP {}
  endscript
}
EOF

mkdir /etc/cron.minutely

cat <<EOF > /etc/cron.minutely/0logrotate.hourly
/usr/sbin/logrotate  /etc/logrotate.hourly/haproxy
EOF

chmod 750 /etc/cron.minutely/0logrotate.hourly
 
cat <<EOF > /etc/cron.d/0minutely
# Run the hourly jobs
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
* * * * * root run-parts /etc/cron.minutely
EOF

chmod 640 /etc/cron.d/0minutely

Linux에서 삭제된 파일 물고 있는 프로세스 찾는 방법

warpmemory — Thu, 8 Jun 2023 20:48:43 +0900

lsof +L1

git에서 시크릿 파일 삭제 방법

warpmemory — Mon, 29 Mar 2021 15:39:17 +0900

시크릿 데이터가 원격 저장소에 저장되었을때 삭제 방법입니다.

git filter-branch --force --tree-filter 'rm -f etc/*' --prune-empty HEAD

git push --force origin master

Linux에서 tcpdump 시간 단위로 pcap 파일 생성

warpmemory — Wed, 30 Dec 2020 10:57:44 +0900

tcpdump.sh 스크립트 생성

#/bin/bash
export PATH=$PATH:/usr/bin:/usr/sbin
DUMP_NAME="api"
DUMP_DIR="/root"
DUMP_FILE="${DUMP_NAME}_%Y-%m-%d_%H:%M.pcap"
find $DUMP_DIR -name "${DUMP_NAME}_*.pcap" -mtime +2 -delete
ps -ef |egrep "tcpdump .* ${DUMP_DIR}/${DUMP_FILE}" |grep -v grep |awk '{print $2}' |xargs kill -3 > /dev/null 2>&1
timeout 24h tcpdump -i eth0 port 80 -G 3600 -w ${DUMP_DIR}/${DUMP_FILE} > /dev/null 2>&1 &

crontab -e 로 스케줄러 등록

# restart tcpdump
0 0 * * * /root/tcpdump.sh > /dev/null 2>&1

PostgreSQL 테이블 Vacuum 모니터링

warpmemory — Mon, 20 Jul 2020 11:25:09 +0900

SELECT datname, age(datfrozenxid) FROM pg_database ORDER BY age(datfrozenxid) desc;

         datname         |    age     
-------------------------+------------
 aaaaaaaaaaaaaaaa        | 1485485076
 bbbbbbbbbbbbbbbbbbbbbbb | 1481342364
 cccccccccccccccccccc    | 1461333757
 dddddddddddddddddd      | 1330037484
 postgres                | 1329674313
 fffffffff               | 1156326849
 ggggggggggggggggggggggg |  100464636
 template1               |     382402
 template0               |     378203
(9 rows)

데이터베이스의 수명이 20억 트랜잭션 ID에 도달하면, 트랜잭션 ID(XID) 랩어라운드가 발생하고 데이터베이스는 읽기 전용이 됩니다.

타임라인 및 검색 시스템 설계

warpmemory — Thu, 2 Jul 2020 14:01:24 +0900

사전 지식

사용기술

AWS
- Elastic Load Balancing(ELB)
- Elastic Computing(EC2)
- ElastiCache(Redis Cluster)
- Elasticsearch(ELK)
- EC2 Autoscailing
Linux
- CentoOS
Nginx
- UWSGI
Python
- Django
- Celery
MySQL
Kafka
Storm

개발 사전 체크

기획 내용의 검토

Timeline 시나리오 설계 및 구축
1. 특정 유저가 다른 유저 혹은 인플루언서를 팔로우할 경우 모아보기를 지원해야 함
2. Only DB Query로 구축은 지양하고, 확장성 및 성능을 고려한 설계 필요(DB로 설계했을 때 방안도 고려)
AWS ELK를 활용한 검색 시나리오 설계 및 구축
1. 사용자가 작성한 글/크롤링한 데이터/커뮤니티 검색 지원

해결하고자 하는 문제

확장성 및 성능을 고려한 Timeline 시스템 구축
데이터 크롤링 및 검색 시스템 구축

개발 범위

Timeline 시스템
- 사용자가 post 시 팔로워 timeline에 post 추가
- Only DB Query 구축 지양, 확장성 및 성능을 만족
  - Redis 클러스터를 이용한 캐시 시스템
검색 시스템
- 크롤링 시스템
  - URL, Keyword 등 설정에 따른 크롤링
  - 크롤링 사이트, 속도 제한
- 파이프라인 시스템
  - 데이터 버퍼링
  - 데이터 유실 없어야 하고
  - 장애 내성
- 스트림 프로세싱
  - 파싱
  - 필터링
  - 인덱싱
- 검색 시스템
  - 데이터 저장
  - 검색
  - 검색 결과 랭크
- 통계 시스템
  - 인덱스 통계
  - 검색 통계
- 캐시 구축
  - 검색 결과 캐시
- API 구축
  - 검색
  - 검색 결과 랭크
  - post 등록 시 검색 인덱스 저장

주요 프로세스 및 시나리오

시스템 구성 및 프로세스

핵심 로직

Timeline 시스템

MySQL 구성

Relational Database Service(RDS)가 EC2 기반으로 서비스됨
비용 측면에서 RDS 사용하지 않고, EC2에 직접 DBMS 구축해서 사용해도 됨
DB 이중화 및 주기적인 백업 시스템 필수
멀티 마스터 구조 또는 Master - Slaves 구성인 경우 라이브러리 단에서 Read/Write 구분하여 사용
데이터가 많아지면 데이터 베이스 샤딩/파티셔닝 고려
운영 이슈가 심각해지면 RDS로 이전 고려

MySQL 스키마

CREATE TABLE `user` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `email` varchar(256),
  `name` varchar(256),
  `influencer` char(1) DEFAULT 'f',
  `created_at` datetime DEFAULT '0000-00-00 00:00:00',
  PRIMARY KEY (`id`),
  UNIQUE KEY `IDX_user_email` (`email`),
  KEY `IDX_user_name` (`name`),
  KEY `IDX_user_influencer` (`influencer`),
  KEY `IDX_user_created_at` (`created_at`)
) ENGINE=INNODB DEFAULT CHARSET='utf8';

CREATE TABLE `follower` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `user_id` int(10) unsigned,
  `follower_user_id` int(10) unsigned,
  `created_at` datetime DEFAULT '0000-00-00 00:00:00',
  PRIMARY KEY (`id`),
  KEY `IDX_follower_user_id` (`user_id`),
  KEY `IDX_follower_created_at` (`created_at`),
  FOREIGN KEY (`user_id`) 
  REFERENCES user(`id`) ON UPDATE CASCADE ON DELETE RESTRICT
) ENGINE=INNODB DEFAULT CHARSET='utf8';

CREATE TABLE `post` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `user_id` int(10) unsigned NOT NULL,
  `contents` text NOT NULL,
  `tags` text,
  `locale` varchar(256) NOT NULL DEFAULT '',
  `created_at` datetime DEFAULT '0000-00-00 00:00:00',
  PRIMARY KEY (`id`),
  KEY `IDX_post_user_id` (`user_id`),
  KEY `IDX_post_locale` (`locale`),  
  KEY `IDX_post_created_at` (`created_at`),
  FOREIGN KEY (`user_id`) 
  REFERENCES user(`id`) ON UPDATE CASCADE ON DELETE RESTRICT
) ENGINE=INNODB DEFAULT CHARSET='utf8';

MySQL 타임라인 조회

사용자의 팔로워가 많아지면 많아질수록 부하 문제 발생

SELECT
    *
FROM
    post
WHERE
    user_id in (
        SELECT
            user_id
        FROM
            follower
        WHERE
            follower_user_id = {user_id}
    )
    OR user_id = {user_id}
ORDER BY created_at DESC LIMIT 20;

MySQL 사용자가 팔로우하는 인플루언서 조회

SELECT
    u.id, u.influencer
FROM
    follower AS f JOIN user AS u ON u.id=f.user_id
WHERE
    f.follower_user_id={user_id} AND u.influencer='t';

Redis 스키마

키 : 벨류

USER_{user_id}_INFLUENCERS : Sets(1, 3, 5, 7)
USER_{user_id}_FOLLOWINGS : Sets(2, 4, 6, 8)
USER_{user_id}_POSTS : Lists[1, 2, 3, 7, 8, 9]
POST_{post_id} : Strings '{
    "user_id": 1,
    "user_name": "사용자1",
    "contents": "포스트1",
    "created_at": "2020-07-02 10:09:10"
}'

Redis 타임라인 조회

Redis 클러스터에 액티브(2주 안에 접속한) 사용자에 대한 타임라인을 미리 생성 저장하여 서비스
- 캐시가 없는 경우에는 MySQL에서 가져와서, 캐시 생성
- ttl 시간을 2주로 설정, 해당 키 접근 시 마다 ttl 시간이 2주가 되도록 설정
인플루언서의 post가 아닌 경우는, post 등록 즉시 팔로워들의 POSTS 캐시에 바로 추가(Push 방식)
인플루언서의 post인 경우는, 팔로워가 접속했을 때, 팔로워의 POSTS 캐시에 인플루언서 포스트를 가져와 병합(Pull 방식)
MySQL과 최종 정합성 고려

API 서버

EC2로 구축
- Nginx : 웹 서버
- uWSGI(Web Server Gateway Interface) : Nginx서버와 Python 애플리케이션 간 통신 인터페이스 모듈
- Django REST framework(DRF) : Django RESTful 프레임워크
- REST Swagger : API 문서 자동화
Amazon EC2 Autoscailing 사용하여, 서버 부하에 대응
RESTful 조건에 만족하도록 개발
GET /api/v1/posts
- user_id
POST /api/v1/posts
- user_id
- contents
- tags
- locale

Celery 서버

비동기 태스크 큐로 post가 들어왔을 때, Redis 클러스터에 Timeline Cache 생성

검색 시스템

수집(Crawler)

검색 대상 URL 및 검색 키워드 설정에 따라 데이터 수집
- 수집 대상 설정 가져오는 기능
crawler 속도 제한 기능 필수
robots.txt 확인하여, crawler 제한된 사이트 제외
사이트 도메인별로 Kafka 토픽 데이터 저장(스트림 프로세싱 단순화)
- Twitter
- Facebook
- YouTube

파이프라인(Kafka 클러스터)

EC2로 Kafka 클러스터(+Zookeeper) 파이프라인 구축
- Consumer가 broker로 부터 메시지를 pull 하는 방식
  - Consumer가 처리 가능할 때 메시지를 가져와 처리
    - 자원 효율적 사용
  - 메시지를 disk에 저장 하기 때문에 이미 처리한 큐도, 다시 가져와서 처리가 가능 함
    - Consumer 장애 시에도 데이터 누락 없이 처리 할 수 있음
  - 메시지를 쌓아 두었다가 한번에 처리하는 배치 처리도 가능
- 클러스터로 장애 내성을 갖음
데이터 규모에 따라서 클러스터 규모 산정
- 최소 설정은 3개 클러스터에 복제 1개 이상
수집 데이터 보관 기간 설정(log.retention.hours=72)
- 수집 용량 및 스트림 스로세싱 시스템 장애등을 고려해서 조정

스트림 프로세싱(Storm 클러스터)

EC로 Storm 클러스터(+Zookeeper) 스트림 프로세싱 구성
- 분산 처리 프레임워크로 사용
파이프라인으로 들어온 데이터 가공
- 필터링
  - 중복 데이터 제거
- 파싱
  - 도메인 및 데이터 타입별로 데이터 파싱
- 필터링
  - 중복 데이터 제거
- 인덱싱/태깅
  - 인덱스 생성
- 메타데이터 생성
  - 날자
  - 지역

검색 시스템(Elasticsearch 클러스터)

스트림 프로세싱으로 가공된 검색 데이터 저장
- url
- title
- summary
- content_type
- created_at
- locale
- tags
- click_count
검색 정보 저장
- keyword
- locale
- created_at
Query 기능

통계 시스템(Kibana)

인덱스 통계 데이터 제공 및 시각화

캐시 시스템(Redis 클러스터)

검색 결과를 캐시

API 서버

Timeline API 서버 구성 사용

Celery 서버

비동기 태스크 큐 처리
- 검색 키워드 저장
- 검색 결과 클릭 카운팅
- 검색 결과 캐시 생성
- 신규 포스트 데이터 검색 시스템에 저장

모니터링 시스템

처리량 모니터링
- 부하 발생 하거나, 유입량 보다 처리량이 낮으면 노티
- 스케일 아웃 처리
에러 모니터링
- 에러 발생시 노티

Linux find 명령어로 날자별 디렉토리 파일 이동 및 복원

warpmemory — Mon, 15 Jun 2020 18:20:32 +0900

1
2
3
4
5
6
7
8
9
10
# 날자별 디렉토리 이동
find /home/hosting/webanalyzer/data/db/*/* -maxdepth 1 -type d -name "`date +'%Y%m' -d '1 year ago 1 month ago'`" -exec bash -c 'basedir=$(dirname {}) && mkdir -p /home/_trash$basedir && mv {} /home/_trash$basedir' \;
 
find /home/hosting/webanalyzer/data/db/*/* -maxdepth 1 -type d \( -regex '.*2018[01][0-9]$' -or -regex '.*20190[1-5]$' \) -exec bash -c 'basedir=$(dirname {}) && mkdir -p /home/_trash$basedir && mv {} /home/_trash$basedir' \;
 
 
# 이동된 디렉토리 
find /home/_trash/home/hosting/webanalyzer/data/db/*/* -maxdepth 1 -type d -name "`date +'%Y%m' -d '1 year ago 1 month ago'`" -exec bash -c 'basedir=$(dirname {}) && targetdir="${basedir#/*/*/}" &&  mv {} /$targetdir' \;
 
find /home/_trash/home/hosting/webanalyzer/data/db/*/* -maxdepth 1 -type d \( -regex '.*2018[01][0-9]$' -or -regex '.*20190[1-5]$' \) -exec bash -c 'basedir=$(dirname {}) && targetdir="${basedir#/*/*/}" &&  mv {} /$targetdir' \;
cs

웹 사이트 SSL/TLS 지원 프로토콜 확인

warpmemory — Wed, 25 Mar 2020 19:50:52 +0900

2020년 상반기에 4대 주요 웹브라우저 회사인 Google, Microsoft, Apple, Mozilla의 브라우저에서 TLS 1.0 및 1.1 지원을 종료한다고 합니다. 현재 TLS 프로토콜은 TLS 1.0, 1.1, 1.2, 1.3의 4가지 버전이 있지만, 1.0, 1.1은 POODLE 및 DEAST와 같은 공격에 취약한 것으로 알려져 있습니다. 이에 OpenSSL을 명령어로 프로토콜에 따라서 접속이 가능한지 확인 하는 방법을 소개합니다.

OpenSSL로 프로토콜 접속 테스트

openssl의 s_client 명령어와 프로토콜 옵션을 넣어서, 특정 프로토콜로 접속이 가능한지 확인할 수 있습니다. 정상적으로 접속이되면, 인증서 정보 및 접속 정보가 출력되고 종료 됩니다.

# openssl s_client -connect naver.com:443 -tls1  
CONNECTED(00000003)
depth=3 /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
verify return:1
depth=2 /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
verify return:1
depth=1 /C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Organization Validation Secure Server CA
verify return:1
depth=0 /C=KR/postalCode=13561/ST=Gyeonggi-do/L=Seongnam-si/streetAddress=6, Buljeong-ro/O=NAVER Corp./OU=Information Security Team/OU=Hosted by Korea Information Certificate Authority, Inc./OU=PremiumSSL Wildcard/CN=*.www.naver.com
verify return:1
---
Certificate chain
 0 s:/C=KR/postalCode=13561/ST=Gyeonggi-do/L=Seongnam-si/streetAddress=6, Buljeong-ro/O=NAVER Corp./OU=Information Security Team/OU=Hosted by Korea Information Certificate Authority, Inc./OU=PremiumSSL Wildcard/CN=*.www.naver.com
   i:/C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Organization Validation Secure Server CA
 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Organization Validation Secure Server CA
   i:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
 2 s:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
 3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHnTCCBoWgAwIBAgIRAPG4tSHPCotEtG1VzRODH4owDQYJKoZIhvcNAQELBQAw
gZUxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE9MDsGA1UE
AxM0U2VjdGlnbyBSU0EgT3JnYW5pemF0aW9uIFZhbGlkYXRpb24gU2VjdXJlIFNl
cnZlciBDQTAeFw0xOTA0MTAwMDAwMDBaFw0yMTA0MjgyMzU5NTlaMIIBFjELMAkG
A1UEBhMCS1IxDjAMBgNVBBETBTEzNTYxMRQwEgYDVQQIEwtHeWVvbmdnaS1kbzEU
MBIGA1UEBxMLU2VvbmduYW0tc2kxFzAVBgNVBAkTDjYsIEJ1bGplb25nLXJvMRQw
EgYDVQQKEwtOQVZFUiBDb3JwLjEiMCAGA1UECxMZSW5mb3JtYXRpb24gU2VjdXJp
dHkgVGVhbTFAMD4GA1UECxM3SG9zdGVkIGJ5IEtvcmVhIEluZm9ybWF0aW9uIENl
cnRpZmljYXRlIEF1dGhvcml0eSwgSW5jLjEcMBoGA1UECxMTUHJlbWl1bVNTTCBX
aWxkY2FyZDEYMBYGA1UEAwwPKi53d3cubmF2ZXIuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAri825vCxtjFOswvvlJ0Nm1UEY80kt33LbKmjqFnM
S9CiB7VODBp7e3Sw09F4Q2gu98L3BNEhR245O06ClFUj5mq9JJnGrRGcmjp/PhTJ
puYnPxlHdRXOsAYK/j97GJTpM05Xzzm94N/6Shr6h+LDvtZ7MDc9tNHv5ZquxBxx
tRvfnYAiZp0+zzWocCp2bj2ghvRlhXp7MRhT1S8BV1SwrN1aOjaua2hmjmBC9jav
6VOc72K5jNBhAsPQ0iFYmc1cFCCch6LFQaGXwssDfmVVRjSeRwRwIcJbiyVShaqY
gk9FtgSln3tc1Z60/89PsGgOItpIVoWwk/rgkzSAIkQvRQIDAQABo4IDYjCCA14w
HwYDVR0jBBgwFoAUF9nWJSdn+THCSUPZMDZEjGypT+swHQYDVR0OBBYEFLh6Zc2P
k8619JQ6JoHvw+9/CdsyMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0G
A1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBKBgNVHSAEQzBBMDUGDCsGAQQB
sjEBAgEDBDAlMCMGCCsGAQUFBwIBFhdodHRwczovL3NlY3RpZ28uY29tL0NQUzAI
BgZngQwBAgIwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNv
bS9TZWN0aWdvUlNBT3JnYW5pemF0aW9uVmFsaWRhdGlvblNlY3VyZVNlcnZlckNB
LmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LnNl
Y3RpZ28uY29tL1NlY3RpZ29SU0FPcmdhbml6YXRpb25WYWxpZGF0aW9uU2VjdXJl
U2VydmVyQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNv
bTApBgNVHREEIjAggg8qLnd3dy5uYXZlci5jb22CDXd3dy5uYXZlci5jb20wggF9
BgorBgEEAdZ5AgQCBIIBbQSCAWkBZwB1ALvZ37wfinG1k5Qjl6qSe0c4V5UKq1Lo
GpCWZDaOHtGFAAABagYQtsUAAAQDAEYwRAIgcvnYKlDj5iiMyXUXDZaL+3klOjFl
1kpDV8smCZmgrsUCIFLq43RudmteYHp/Vz13MfOjpeQ1spviyauCe/zA9XVzAHYA
RJRlLrDuzq/EQAfYqP4owNrmgr7YyzG1P9MzlrW2gagAAAFqBhC2xAAABAMARzBF
AiAGC+BNdF49ESvhqGhprDN0SndEXXp8Bvu8lCgPpJGkJgIhANuhe20ajyfGk0m5
e07meCD6NP5roWv/kdtA9yESZsITAHYAXNxDkv7mq0VEsV6a1FbmEDf71fpH3KFz
lLJe5vbHDsoAAAFqBhC27gAABAMARzBFAiB4z/lDFMMQDEIR7HuYO5m2oVFVgsyG
slTJz9S9OUVhmQIhAO2S+srpfoOTAYLYXStlidzGdOql4RUuCUOUyhJ1/eybMA0G
CSqGSIb3DQEBCwUAA4IBAQAOYLCmqVASHh1ybN8AMGpTvnVglf4G7EOZVffQ0A/b
EZzfKT1amG6Ha24P5REPZs81/nHH0biLTN5LusRU9wPWzxpnxyZKAsyuPP9zxc9K
2h0quJIEZMTNy6JDP1BU6BHnGlz7TeuLfmcm/H3EeKcU6m5LiyB+W8q5c7ND5Sv6
/nIuwZolhF2EeLjVZ+gTFjvqEaBtnXLWyNr7XIV5xpqSXyFDOeHcRfTVA7UZH3j/
JmmmIlwcdsvUAZ1nNXxFX/xQ1C5aiqe0fJuLTa8glfPzYvZwjG88Kx0KFSvcbFEF
rCcMKOi42bm/30le9Ul2rHH4wLaGoZemkjz0uxDbanpR
-----END CERTIFICATE-----
subject=/C=KR/postalCode=13561/ST=Gyeonggi-do/L=Seongnam-si/streetAddress=6, Buljeong-ro/O=NAVER Corp./OU=Information Security Team/OU=Hosted by Korea Information Certificate Authority, Inc./OU=PremiumSSL Wildcard/CN=*.www.naver.com
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Organization Validation Secure Server CA
---
No client certificate CA names sent
---
SSL handshake has read 6174 bytes and written 413 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES128-SHA
    Session-ID: 6BCE041B1F64BC3876272307D8B4AA679C5319FF7592FF97A5CBE75137CAFBFA
    Session-ID-ctx: 
    Master-Key: 819D24CDBECE180F26286CEE10AF96BBB34BDF98D1A0A5F24638CB7D117DE795A39639ABB5FD37AA63EEB2CB0B0B2BF4
    Key-Arg   : None
    Krb5 Principal: None
    Start Time: 1585117802
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---
closed

프로토콜 옵션은 다음과 같습니다.

Option	Description
-ssl2	just use SSLv2
-ssl3	just use SSLv3
-tls1_2	just use TLSv1.2
-tls1_1	just use TLSv1.1
-tls1	just use TLSv1
-dtls1	just use DTLSv1

crontab 실행 환경 변수 설정

warpmemory — Wed, 25 Mar 2020 19:40:45 +0900

간혹 shell에서 직접 실행하면, 정상적으로 잘 동작하는 스크립트가 crontab에 등록하면 정상적을 동작하지 않는 경우가 발생하곤 합니다. 대부분 shell의 환경 변수와 crontab의 환경 변수가 달라서 발생을 하게 됩니다. 스크립트 내에서 외부 명령어를 실행하는 경우에 PATH 환경변수가 달라서 명령어 위치를 찾지 못해서 에러가 발생하는 경우가 대표적인 예입니다. 이런 문제를 해결하기 위해서 crontab 실행 시 환경 변수를 맞춰서 실행하는 방법을 소개합니다.

환경 변수 확인

현재 로그인된 shell의 환경 변수 값을 확인 하는 방법은 set 명령어를 이용하면 확인 할 수 있습니다.

# set |egrep '^PATH'
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

/etc/crontab 수정

/etc/profile, /etc/profile.d/* 설정을 통해서 shell 로그인시 환경변수를 수정할 수 있는 것처럼, /etc/crontab 파일에서 crontab 실행 환경 변수 설정을 할 수 있습니다.

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root

# For details see man 4 crontabs

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name  command to be executed

위 설정은 crontab 전역 설정이라고 보면되는데, crontab은 설정 순서

crontab 실행 시 환경 변수 지정

crontab 설정의 실행 명령에 환경변수를 포함하여, 실행할 수 있습니다. 예를 들어 /root/backup.py 스크립트에서 /usr/local/bin/rsync 명령어를 사용하여 파일 싱크를 해야 한다면,

import os

os.system("rsync -a /home /home_backup")

crontab 실행 시에 PATH=/usr/local/bin을 앞에 넣어서 실행하게 되면, /usr/local/bin/rsync 절대 경로가 아닌 rsync 로만 실행을 한경우에도 /usr/local/bin/rsync가 실행되게 됩니다.

0 5 * * * PATH=/usr/local/bin /root/backup.py

Apache 접속 인증 추가 두가지 방법

warpmemory — Tue, 24 Mar 2020 18:24:36 +0900

Apache 접속 인증 추가는 .htaccess에 인증 설정을 추가하는 방법이 가장 잘 알려져 있고, 많이 사용되고 있습니다.

단, .htaccess는 디렉토리 설정으로 Apache에서는 httpd.conf에 설정된 directory 설정과 해당 경로의 .htaccess 파일중 하나만 인식하는 문제가 있습니다. 그렇기 때문에 접속 인증만 추가해야하는 경우에는 virtualhost 설정에 location 설정을 통해서 .htaccess를 사용하지 않고, 인증 설정을 할 수 있습니다.

패스워드 파일 생성

# htpasswd -c /home/warpmemory/www/secret/.htpasswd warpmemory
New password: mypassword
Re-type new password: mypassword
Adding password for user warpmemory

/home/warpmemory/www/secret/.htpasswd 파일에 warpmemory 사용자 패스워드 설정을 합니다.

방법1) .htaccess 또는 Directory 설정

AuthType Basic
AuthName "Restricted Files"
AuthUserFile /home/warpmemory/www/secret/.htpasswd
Require user warpmemory

만약, /usr/local/apache/htdocs/secret 디렉토리를 보호하려면, 아래 지시어를 /home/warpmemory/www/secret/.htaccess 파일이나 httpd.conf의 <Directory /home/warpmemory/www/secret> 섹션에 위 설정을 적으면 됩니다.

방법2) httpd.conf에 VirtualHost Location 설정

<Virtualhost *>
    ServerName warpmemory.com
    ServerAdmin postmaster@warpmemory.com
    DocumentRoot /home/warpmemory/www
    <Location "/secret">
        AuthType Basic
        AuthName "Restricted Content"
        AuthUserFile /home/warpmemory/www/secret/.htpasswd warpmemory
        Require valid-user
    </Location>
</VirtualHost>

httpd.conf의 Virtualhost 설정에 위처럼 Location 설정을 추가하고,

# apachectl configtest
Syntax OK
# apachectl graceful
apachectl graceful: httpd gracefully restarted

설정 체크 및 재시작 해주면 됩니다.

인증(Authentication), 권한부여(Authorization), 접근제어(Access Control) - Apache HTTP Server Version 2.4

인증(Authentication), 권한부여(Authorization), 접근제어(Access Control) 이 문서는 최신판 번역이 아닙니다. 최근에 변경된 내용은 영어 문서를 참고하세요. 인증(authentication)은 자신이 누구라고 주장하는 사람을 확인하는 절차이다. 권한부여(authorization)는 가고 싶은 곳으로 가도록 혹은 원하는 정보를 얻도록 허용하는 과정이다. 당신의 웹사이트에 있는 정보가 소수의 사람들만의 비밀이거나 이들만을

httpd.apache.org