apache2 설정 파일 더 알아보기

Amazon Linux, CentOS, Fedora, RHEL(Red Hat Enterprise Linux) : yum, httpd Debian, Ubuntu : apt, apache2

대신에 /etc/httpd/conf/httpd.conf 파일을 확인해보니 있었다 !

물론 직접 가져와서 역으로 CentOS에서 apt-get 설치하거나, Ubuntu에서 yum을 설치해서 활용할 수는 있는 것 같다. 생각해보면 나도 억지로 깔아봤던 경험이 있다. 그 때는 정말 아무것도 모르고 패키지가 급해서 그렇게 했던 것 같기도 하다. 알고 가면 좋으니 정리해본다.

httpd.conf에서 index 우선순위에 대한 설정을 index.html 말고 따로 적어둔 것이 없는 default 상태를 유지했다. 그리고 나서 index.html 없이 index.php만 넣을 경우 index.html이 없으니 안될 줄 알았는데 index.php가 제대로 떴다. 이 상태에서 추가로 index.html을 넣었더니 다시 index.html가 메인으로 떴다.

https://www.quora.com/Why-is-it-when-you-have-an-index-PHP-and-index-HTML-in-the-primary-folder-used-to-host-my-website-index-PHP-takes-priority-first-and-whenever-I-load-my-site-index-PHP-loads-as-the-homepage-instead-of-index-HTML

우선순위를 전혀 설정하지 않았음에도 되는 이유에 대한 링크인 것 같은데 다시 읽어보고 수정해야지..

클라이언트(리눅스) - 서버(리눅스)

SSH 접속을 위해 크게 서버 인증, 사용자 인증의 2가지 단계를 거치게 된다고 한다.

시작에 앞서 서버 환경에 SSH 서버(데몬) 설치 시에 Public Key(공개키), Private Key(개인키, 비밀키, 비공개키) 2개를 Key Pair로 생성하게 된다.

실제 클라이언트가 서버에 접속을 시도할 때, 서버에서 공개키를 클라이언트에 전달하게 된다. 그 때 해당 공개키는 클라이언트의 .ssh/known_hosts에 저장이 된다. 그리고 후에 접속을 시도할 때 마다 known_hosts 파일에 등록되어있는지 확인하여 있으면 믿을 수 있는 서버로 인식한다.

그리고 그 다음에는 반대로 클라이언트 쪽에서 생성된 공개키를 서버에 전송하여, 서버의 .ssh/authorized_keys에 추가하게 된다.

자세한 프로세스는 잘 설명된 블로그 링크들이 많으니 참고하면 되겠다.

내 기준 최고의 구조도 & 설명 블로그 링크 ^^

설명은 이해를 했는데 직접적으로 ssh 설치를 해서 접속 시도하는 것이 아니라,

Windows에서 PuTTY를 사용해서 AWS EC2 SSH 접속을 시도하려고 할 때 대체 known_hosts가 어디에 있길래 서버 인증이 되어서 접속이 되는 지가 궁금했다.

흔히들 블로그에서 깔끔하게 사용법을 설명해주는 .pem 파일을 .ppk로 변환해서 SSH 접속 시에 활용하는 부분은 알겠는데.. 이건 사용자 인증이지 내가 궁금했던 부분이 아닌 것 같았다.

우선 가장 최초에 EC2 인스턴스에 PuTTY로 윈도우에서 접속을 시도하면 다음과 같은 창이 뜬다.

• Connect Once: 이번 한 번만 연결 허용, 다음에 다시 접속하면 위 경고창 또 뜬다.
• Accept: 캐싱해서 다음에 다시 접속하면 위 경고창 뜨지 않는다 (믿겠다는 뜻 ^^)

여기서 Connect Once를 누르고 나서 PuTTY에서 관리하는 known_hosts 를 찾아가보자

1. Windows 검색창에서 regedit을 치거나 Registry Editor(레지스트리 편집기)를 검색하여 들어간다.

2. 컴퓨터\HKEY_CURRENT_USER\SOFTWARE\SimonTatham\PuTTY\SshHostKeys 경로로 탐색해서 들어간다.

들어가면 이렇게 나오는데, 아무것도 없다. 서버쪽에서 클라이언트로 공개키를 보냈는데 Connect Once를 눌렀기 때문에 일회성 접속으로만 처리가 되어서 저장된 게 없다. 다음에 재접속할 때 또 검증을 요구하게 된다.

3. 다시 EC2 인스턴스에 PuTTY로 접속 시도한다. 이번에는 Connect Once가 아니라 Accpet를 해본다.

4. Registry Editor에서 SshHostKeys 파일 안에 뭐가 생겼는지 재확인해본다.

짜잔~!!!

5. 인스턴스 재접속을 시도해본다. 이제 경고창 없이 바로 서버에 대한 인증이 넘어간다.
6. 임의로 Registry Editor에서 등록되어 있는 SshHostKeys의 값을 지워버리면, 인스턴스 재접속시 다시 경고창이 뜬다.

매번 아무 생각 없이 접속하던 내용을 깊게 이해해보려고 했더니 시간을 너무 많이 쏟았다. 공부해야 할 것이 끝도 없다..

틀린 부분은 설명과 함께 달아주시면 바로 수정하겠습니다만.. 저격/지적 어투는 답댓 안 달아드릴거에유 (댓글 달려본 적 없음..)

Ingress Nginx Controller를 internal 설정으로 설치를 한 상태였다.

kubectl get svc 

Ingress Nginx Controller를 조회해봤을 때,

ingress-nginx-controller (이건 external이라고 앞으로 부르겠다) ingress-nginx-controller-internal

이렇게, internal 용으로도 추가로 생성이 제대로 되어 있었다.

실제 궁금했던 케이스는 이렇다

• A의 도메인으로는 아무 네트워크를 사용해도 쉽게 접속이 된다.

• B의 도메인으로는 내부망으로만 접속이 된다.
• A과 B이 모두 가르키는 곳은 공통적으로 C service이다.

A는 External Ingress Nginx Controller를 통해 접속하는 것이고, B는 Internal Ingress Nginx Controller를 통해 접속하는 것이다.

Ingress 규칙에서 각각 A, B는 모두 backend로 연결되는 service가 C로 동일하게 설정되어 있었다다. 고로 .. A, B는 Ingress 규칙이 완전히 똑같았다. (Ingress 이름만 제외하고는)

여기서부터 헷갈리기 시작했던 것이, ingress를 각각 describe해서 보니 2개 다 완전히 내용이 똑같았는데, Address 부분이 external ingress nginx controller의 IP 주소로 똑같이 고정되어 있었다.

kubectl describe ingress A가-연결된-ingress-이름
kubectl describe ingress B가-연결된-ingress-이름

A는 External 연결이니까 그렇다치는데, B는 ingress nginx controller internal의 IP 주소로 고정되어 보여야하는 것이 아닌가? 라는 생각을 했고, 이것 때문에 모든 것들이 갑자기 다 헷갈려지기 시작했다.

그래서 A, B에 대한 nslookup을 해서 address를 조회해보니 이 부분은 내 예상대로 A의 address는 ingress nginx controller external의 IP 주소였고, B의 address는 ingress nginx controller internal의 IP 주소였다.

위와 같은 과정을 겪다 보니까 내가 뭘 하고 있는지 나도 모르겠는 지경에 왔다. 근데 답은 너무 단순했다. 그냥 내가 엄청 헷갈렸던 것 같은데..

internal ingress nginx를 쓸 지 external ingress nginx를 쓸 지는 순전히 작업자가 무슨 ip로 도메인을 등록하느냐에 달린 거다. 그리고 이 경우는 B에 특별히 ingress nginx controller internal의 IP를 등록해준 것 뿐인 것이다.

DNS 등록을 내가 하지 않았던 환경이어서 이렇게 단순한 거를 완전 뱅뱅 돌고 돈 것이다.. internal용으로 생성된 ingress nginx controller를 고를 지, 아닌 것을 고를 지.. 대체 어떤 manifest에서 셋업이 되었을까? 하면서 엄청 파일 뒤져보고 구글링했었는데..

얕은 지식과 섞이는 바람에 나 혼자 대차게 헛구글링만 한거다~

그래도 하나 얻은 건 있다.

2개가 나란히 생겼을 때 ingress object는 기본적으로 external을 향하고 있다는 것 정도는 알게 됐다. 그래서 아마 처음에 ingress를 2개 동시에 조회했을 때 모두 external에 대한 ip 주소만 뜨지 않았을까?

그래서 이것의 장점은, 새로운 ingress controller를 설치하지 않고 1개로 여러가지 방향으로 운용할 수 있다.. 인 것 같다. 기초가 항상 중요하다는 걸 또 배운다. 자꾸 삽질 블로그가 되는 것 같은데

rsync -av src/ dest

위 문장은 rsync 명령을 수행할 때에 현재 상태에 대해서 src directory 밑의 모든 파일/디렉토리를 dest 디렉토리 밑에 동일하게 remote sync를 하는 명령어이다.

그래서 나는 너무 당연히 한 번만 수행하면 계속 실시간으로 동기화 해주는 것이라고 이해를 해버린 것이다.

그럼 어떻게 해야 rsync의 실시간 동기화를 끊지..?

한글로 검색했을 때는 딱히 나같은 (잘못된) 호기심을 지닌 사람이 없어서 영문으로 구글링하니까 바로 나오더이다.

https://www.reddit.com/r/linux4noobs/comments/l3wkdp/how_to_stop_rsync_from_syncing_files_anymore/?rdt=59109

근데 댓글 읽다가 알게 됐다. 내가 rsync를 너무 대충 이해하고 있었구나.. 실시간으로 동기화한다는 말에서 실시간에만 초점을 두는 바람에 개념을 완전히 잘못 이해해버렸다. 이제는 알았으니 됐다 !!!

다소 멍청했지만.. 나같은 사람도 있어야 밸런스가 맞지 :)

find . -type f -size +10000k -exec rm -f {} \; ## 현재 위치에서 파일 사이즈 10000k 넘어가는 파일들을 모두 찾아서 삭제하는 커맨드

find /var/www -type d -exec chmod 2775 {} \; ## /var/www 위치에서 디렉토리를 모두 2775 권한으로 변경 (2는 setgid)
-exec 명령어 {} \;

{} : find로 찾은 파일들을 의미
\; : -exec 옵션의 끝을 의미

2. usermod (사용자 계정 정보를 수정하는 명령어)

usermod -a -G apache ec2-user

-a : -G과 같이 쓰이는 옵션, --append
-G : 그룹 추가

apache 그룹에 ec2-user 계정 추가

3. chown (change owner)

chown -R ec2-user:apache /var/www

-R : recursive

/var/www 디렉토리와 하위 디렉토리 & 파일의 모든 소유권을 ec2-user 유저와 apache 그룹으로 변경

echo -n "문자열 입력 받기: " ## 줄바꿈 안하는 옵션 -n
read str_value ## scanf 같은 함수
echo $str_value ## 변수 출력할 때는 항상 $ 표시를 같이 넣어준다 

if [ $option == 'y' ] ; then ## 띄어쓰기 꼭 해줘야함
 echo "yes" ## tab 키로 줄바꿈
else echo "no"
fi ## if 조건문 마무리할 때 써줘야하는 단어

== 와 =의 기능이 동일하므로 실수로 ==를 =로 지정해도 조건문 비교하는 데에는 문제가 없었다.

3. sed 활용한 문자열 바꾸기

   sed -i '/hello/c\hello world' file.txt ## hello가 들어가있는 해당 줄을 아예 hello world로 변경한다

sed 테스트해보기 좋은 사이트

환경: Ubuntu 20.04 (wsl2)

똑같이 따라했는데 이상하게 나는 크론탭에 등록된 스케줄이 돌지 않았다. 로그를 보려고 열심히 뒤져봤지만, syslog 디렉토리 자체가 없어서 확인도 어려웠다. 실습 환경과 내 환경이 동일하지 않아서 발생하는 일이겠거니 싶어서 구글링에 들어갔다. (syslog 관련해서는 나중에 차차 보기로..)

cron이 켜져있는 지 확인을 해봐야한다는 말에 아차! 싶었다.

1. 일단 cron이 설치되어 있는지 확인 (당연히 있겠지.. 제발)

   /etc/init.d
   find /etc -name "cron*"  ## 이렇게 찾아도 되겠다.. 

   

2. 명령어 확인

대부분 daemon 명령어는 비슷하지만 혹시 몰라 한 번 더 확인해봤다.

/etc/init.d/cron

어쩐지 sudo service crond start를 하면 crond: unrecognized service가 뜨더라니..

3. 서비스 기동 전 status 확인

   sudo service cron status

4. 서비스 기동

   sudo service cron start

   

5. 크론탭에 등록된 스케줄이 제대로 도는 것 확인 완료 !

ps -ef | grep cron ## 프로세스 확인까지 해줬다

강의 내용 출처: https://www.youtube.com/watch?v=l39yXacR1_s

위 이미지는 ls의 결과 output이 result.txt 파일에 기록되는 리다이렉션하는 간단한 예제이다. 현재는 >가 1개밖에 없으므로 계속 새롭게 덮어쓰는 형태가 될 것이다.

다만 나는 궁금해져버렸다.

캡쳐본처럼 ls -al 하고 난 result.txt의 파일 사이즈와 실제로 열어본 result.txt의 파일 사이즈와 내용이 일치하지 않을까?

아무것도 없는 디렉토리에서 위와 같은 과정을 여러 번 반복해보았으나, 똑같은 수행을 여러번 해도, ls -al 했을 때는 파일 사이즈가 168인데 cat result.txt를 하면 계속 파일 사이즈가 0이었다.

나와 언뜻 비슷해보이는 질문을 2년 전에 올렸던 사람이 있었는데, 해결되지 않은 듯 했다.

꼭 그렇게 중요하지도 않은 거 하나에 꽂히면 그거 알 때까지 찾고 해결을 보거나, 그렇지 못하면 그대로 그냥 하루를 종료하는 성격인지라 또 호기심이 도져버려서 찾아나서기 시작했다.

이것저것 뒤적거리다가 강의 출처인 이고잉 홈페이지의 영상 댓글에서 힌트를 발견하고 구글링을 제대로 다시 해보기 시작했다. 그래! '>' 의 순서대로 처리되는 게 아닐 수 있겠구나 (이제야 알았냐)

왜 redirction한 결과가 empty file로 기록되는 지에 대해 검색했고, stackoverflow 답변은 다음과 같았다.

참조로 많이 달렸던 GNU 공식 사이트의 Redirection 설명도 캡쳐본으로 아래와 같이 추가했다.

결론적으로 *내가 이해한 *Redirection이 진행되는 과정은 다음과 같다.

(틀린 부분은 곱게 지적해주시면 바로 수정 들어가겠습니다)

1. Standard Output으로 지정된 result.txt 파일이 먼저 생성된다
2. '>'는 매번 새로 덮어쓰기때문에 file size 0으로 truncate된다
3. ls 프로세스가 수행된다.
4. ls 수행된 당시에는 result.txt에 무언가 기록되지 않은 시점이니, file size가 여전히 0이고 그 순간을 Redirect시켜서 result.txt에 담는다.
5. Redirect가 되었으므로, 이제는 result.txt에 내용이 기록된, 파일 사이즈가 0이 아니게 기록이 된다.

그래서 캡쳐본을 다시 보면,

ls -al 한 순간은 ls의 프로세스가 모두 다 돌고 redirection까지 끝난 상황이니까 result.txt의 파일 사이즈가 0이 아닌 것인데,

막상 result.txt 파일을 열어보면, ls 하는 그 순간에서는 파일이 막 생성되거나 리셋된 지점이었을테니 파일 사이즈가 0이었다.

재밌다 재밌어.. ㅎ