규링의 잡소리 & 작업장 페이지
개발에 관련된 글들의 집합입니다. ㅇㅅㅇ
리눅스 커맨드 환경에서 계속 쓰다보면 생각지도 못하게 꼬인 짓들을 할 때가 많다. 그럴 때, 어떤 걸 했는지 헷갈려서 이런 저런 생각 막 하다가 결국 history 쳐보는 게 제일 빠르다는 걸 알긴 한데…..
history도 저장하는 커맨드 수가 한정되어 있다. (근데 이건 당연히 그래야..)
근데 history로도 어떻게 할 수 없는 그런 것들은…. 그냥 커맨드 로거 프로그램 같은 것들로 어떻게 해야 한다. 안그러면 진짜…ㅠㅠ
내 기억력이 그렇게 좋지 않다는 걸 요즘들어서 깨닫고 있는지라..
그래서 snoopy를 써서 요즘은 커맨드 로깅을 좀 하고 있다. 쓰는 법은 github에도 나와있고 해서 뭐 여러모로 편하게 설치해서 쓸 수 있고, 이런 걸로 성능저하 신경쓸 정도도 아니고…
이런 툴들 하나하나 알아둬서 나쁠 건 없으니 알아두자.
내가 이 시리즈를 다시 쓸 일은 없을 거라고 생각했다. 왜냐, 오씨의 그 쓰레기짓 같은 일을 설마 더 겪겠어 했거든….
근데 다른 형태로도 겪는다. 개발 아닌 곳에서도 겪는다… 그래서 시즌 2를 적기 시작한다. 진심 최악이다.
이번에는 진짜 회사 it 자원에 대한 이야기를 좀 하려고 한다.
회사에 it 자원은 우리가 개발하는 데 필요한 자원이다. 그러니깐 꼭 있어야 하고, 꼭 잘 되어야 하는 자원이다. 그건 당연히 일의 효율과도 직관된다. 반대로 이런 자원이 제대로 되지 않은 곳에서는 될 일도 안된다.
그 대표적인 것이 바로 똥컴 주는 회사랑 인터넷 느린 회사다. 이건 말도 안되는 거다. 미친거다 진짜로….
컴 느린 거 주는 건 진짜 컴에 대한 개념이 없는 거다. 사무직들 쓰는 컴 주면서 개발하라고 하는 거 진짜… ㅎ 그냥 할 말 없다. 개발용 컴퓨터를 따로 주면서 사무용으로 컴퓨터를 나눠 쓰면 뭐 다행인데…. 그건 나 포함 일부 사람들 뿐이었다. ㅡㅅㅡ
그리고 네트워크 느린거…. 느리다 못해 도중에 끊기는 것도 진짜 미친 거다. 요즘 인터넷 안되는 곳에서 일 어떻게 하냐. 협업 툴도 인터넷 되어야지 되는 세상에! 네트워크 끊기는 것도 절대로 있을 수 없는 일인데 그걸 별 수 없다면서 여기는 놈들이 진짜….
그러면서 어이없는 네트워크 점검한답시고 공지 띄우고 하는꼴 보면서 드는 생각이… 그냥 미쳤다는 생각밖에 없네요.
지금 여긴 네트워크를 그냥 첨부터 싹 다 뜯어내고 다 갈아엎어야 하는 상황인데, ap도 그 낡아빠진 거 다 갈아 버리고 다시 새로 사서 하고, 망 중계기도 100mbps 레벨인 거 아는데 이거 kddi 불러서 죄신껄로 바꾸고 회선망도 다 갈아서 유선으로던 무선으로던 엄청 여유로운 걸로 바꾸면 네트워크 안끊긴다 그런 소리 몇번을 해도 개소리 취급이나 하고…
ㅎ… 그냥 늬들 맘대로 해라. 난 나갈란다.
전 미안하지만 No입니다. 결론부터 말하면, 마스토돈같은 구조에서는 인스턴스 날아가면 그만입니다.
마스토돈이나 그에 관한 비슷한 분산 소셜들이 많이 만들어졌지만 지금 제대로 안되고 했던 이유가 바로 인스턴스에 가입해서 활동하는 도중에 인스턴스가 없어지고 해서 모든 자료 날아가고 하는 것들에 대한 그 무언가가 없습니다. 이게 중앙형 소셜 네트워크는 그냥 그 서비스 하나에서 전체적으로 싹 다 처리하던 걸 분산해서 하니깐… 활동하는 인스턴스가 없어지면 다른 인스턴스에서 새로 시작해야 합니다. 그러면 그 사람에 대한 대화 환경, 대화 창구가 그냥 사라지게 됩니다.
지금까지 만들어지고 없어지고 하는 지금 수많은 인스턴스들은 거의 대부분 개인이 만들어서 시작하고, 그게 사이즈가 커져서 여러 문제 터져서 감당이 안되고 해서 없어진 것들도 정말 많습니다. 그거 보면 옛날에 몇몇 개인들이 만든 사이트에 커뮤니티 활성화 되다가 사이트 없어지고 바이바이 하던 거 생각나더군요.
그래서 전 분산형 소셜 네트워크도 서비스 제공 회사에서 집중적으로 관리하는 인스턴스 집합이 아니면 믿기 힘들다고 봅니다. 분산형이지만 실제로는 중앙에서 어느정도 매니지되고, 그 분산 그룹끼리 연결할 수 있는 고유의 프로토콜화가 잘 된 것이 아니면 어려운 것이라고 판단됩니다. 트히 트위터의 순기능을 많이 본 사람들이 많아서… 수많은 팔로잉, 팔로워를 가진 분들 통해서도 정말 많은 연결과 확장이 발생해서 얻은 이득을 생각하면… 분산 소셜이 보여주는 기능에 대해서는 커뮤니케이션 기능에 한해서는 한정적인 그룹화만 보여주고 끝날 수도 있고 해서 참 골때립니다.
그래서 마스토돈 베이스의 기술을 가지고 서비스화가 된 소셜이 있다면 그 서비스가 유명해질 것이지, 마스토돈 자체가 일반 사용자를 기준으로 유명해지는 그런 사태는 오지 않을 듯 하네요. 일본인들 한정으로 유입이 많은 미스키의 경우처럼 인스턴스 자체에 공개화가 되어있어서 그것까지 연결되어 죄다 미스키라고 하는 그런 기능이나 블루스카이같이 블루스카이 하나로 다 묶여서 그 안에 블루스카이에서 제공하는 인스턴스들 안에서 돌아서 중앙화 처럼 보일 정도면 모를까…
근데 지금 일론 머스크 개새끼에 의한 트위터 대체로 마스토돈이 언급되는 거 땜에… 전 마스토돈의 인스턴스를 지금처럼 개개인이 만든 곳에 여기로 오세요 그러는 수준으로는 그냥 그분들만의 공간으로 있거나, 아니면 관리 못해서 터지거나 그렇게 되고 끝날 가능성이 높아 보입니다.
제 잡소리지만, 진짜 인스턴스 관리에 따라서 소셜 네트워크로의 기능이 될지, 그냥 로컬 커뮤니티의 난립이 될지 모르겠군요.
정말 간만에 블로그에 글 남겨놓습니다. 진짜 바쁩니다. 트위터도 못할 정도로요..ㅠㅠ
뭐, 근황 업뎃하고 밀린 내용 올리고 할 껀데, 일단 요즘 좀 찾은 내용 좀 공유하려고 합니다. 바로 flutter 오류인데… 그냥 모바일 앱 개발만 하시는 분들은 상관 없을텐데, 요즘 나온 stable 버전인 3.7.1 버전 설치하고 나서 flutter doctor -v 하면 아래와 같이 나오는 분들 많을 껍니다. (윈도우 환경입니다.)
윈도우 버전 나왔다면서… 왜 이래..?
윈도우 환경에서 플러터 설치 후에 이렇게 나오면, 뭐 안드로이드 개발쪽에 하려고 하는 거면 별 신경도 안쓸텐데…. 저렇게 뜨는 것도 좀 그럴 껍니다.
게다가 쓰는 환경이 윈도우 11인데….
그래서 일단 저 내용이 뭔지 확인해보니… github 이슈는 이미 closed 되어있네요. 해결 되었다는 건데….
진짜 마지막까지 보면 closed 처리되어있다.
근데 이게 좀 골때리는 것이… 마지막에 나온 해결책이 방금 올린 이미지에 그대로 있다. “master 채널을 이용하라.” 라고요.
……
….수정은 했다. 그러니 그거 써라. 이런 건가…
그래서 일단 말하는대로 master 채널로 이동해서 처리하려고 한다. 하는 방법은 간단하다.
이렇게 하나씩 하면 master 채널로 가서 플러터를 업데이트 하게 된다.
stable 쓰면서 안정적으로 하고 싶었는데… 일단 이걸로 해결 되는지는 봐야지.
플러터 업데이트가 진행되는 것이니 시간은 좀 걸린다. 다 진행되고 나면 flutter doctor -v로 확인해보기로 합니다.
오류는 없어졌습니다.
그러니 github에 나온대로 일단 저 이슈 열려있을 때 사람들이 코드 수정한 거 공유 좀 되더니 master에는 일단 수정이 된 듯 합니다. 근데 아직 stable에는 적용이 안되었나보군요. 현재 master는 보다시피 3.8.0의 pre 버전입니다. stable도 3.8.0 되고 나면 이 오류는 없어져 있겠죠…?
저처럼 별 신경도 쓸 필요도 없는 이 오류가 신경쓰이면, 지금은 일단 master 채널로 이동해서 확인해보시면 될 거 같습니다.
아니, 플러터면서 왜 이런 오류가..!
하고 생각할 수 있는 오류를 가져와봤습니다. 협업하면서 한번씩은 겪을 문제인데, 사실 이걸 모르는 분들은 왜 생기는지 몰라할 수 있어서…..
이런 일이 생기는 건 간단하다. flutter pub이 내가 작업하던 것과 다른 사람이 작업하던 녀석이 충돌해서 그렇다. 내가 개발하다가 넘겨준 부분에 pub 라이브러리를 작업하는 곳에서 새로 업뎃하였다. 그러면서 여러모로 바꿔서 진행한 것도, 새로 추가된 것도 있고..
이러다보니 여러모로 추가된 녀석과 내가 먼저 이용해서 빌드에 이용한 녀석하고 충돌한 거다.
아, 당연하지만, pubspecs.yaml 파일이 충돌한 게 아니다. 이 파일의 내용을 가지고 ios 빌드를 진행해야 하는 CocoaPods가 새로 업뎃해서 받아오고 해야 하는데 그걸 그냥 더 추가하고 넘기는 작업으로만 하다보니 그런 것이다. CocoaPods를 써본 사람들은 알겠지만, 사실 방법 자체는 여러모로 합리적이다. 기존에 이용하는 것들은 이미 .lock 파일로 만들어서 고정해 두고 빠른 작업을 진행하도록 해놓는 것으로 빌드 시간을 단축할 수 있으니깐..
근데 뭐, 내가 쓰다가 이렇게 오류 나면 오류 나는 것이니 풀어줍시다.
그럼 어떻게 하는지 하나하나 따라하면 됩니다. 근데 저기서 알려주는 pod repo update는 쳐봤자 오류납니다.
ios 폴더로 들어갑니다.
그리고 이 일의 원흉인 Podfile.lock 파일을 지워줍니다.
그리고는 위와 같이 pod install –repo-update 를 실행해서 repo를 업데이트 해줍니다. 그러면 pubspecs.yaml에 지정한 녀석들을 받아다가 업뎃을 쫙 진행해줍니다.
그리고 나서 다시 플러터 프로젝트의 루트로 올라가서 flutter clean 명령으로 현재 프로젝트의 빌드 관련 정보로 생성한 녀석들을 싹 지워줍니다.
그러고 나서 다시 빌드를 진행하면 문제 없이 빌드되는 것을 알 수 있습니다.
이건 CocoaPods를 좀 이용해보고 하면 금방 해결할 수 있는데, 처음부터 flutter를 접하면서 여러명과 작업하고 그러다 보면 그냥 보이는 오류여서 좀 정리해봤습니다.
간만에 쓴 블로그가 이런 내용인데 도움 좀 되었으면 좋겠군요. ;ㅅ;
요즘 너무 바빠서….
저도 처음에 설치하고 나서 좀 여러모로 헷갈렸는데, 해당하는 내용이 좀 부실하게 되어있습니다. (배리어 프로젝트의 README.md에 나와있질 않아서요…ㅠㅠ)
설치 후에 실행하고 나면 별 거 없이 실행되겠지 싶을 겁니다. 그리고 내가 주로 쓰는 컴퓨터를 서버로 설정합니다. (서버로 설정한 컴퓨터의 키보드와 마우스를 이용해서 클라이언트를 제어합니다.)
근데, 처음 설치 후에 서버로 설정하고 그냥 서버 설정에서 봐도 뭔가 더 할 게 있나 싶은데… 로그를 보면 다른 상황이죠. ㅠㅠ
갑자기 ssl 인증서를 쓸 수 없다고 합니다. ;ㅅ;
서버는 클라이언트를 자동으로 찾습니다. 그때에 연결을 승인해야 하는데, 그걸 ssl 인증으로 프로그램 내부에서 진행하는 건데, 그걸 위한 인증서가 없다는 것입니다. ;ㅅ; 이건 윈도우, 맥, 리눅스 어디 할 거 없이 서버로 처음 설치하고 실행했을 때에 저렇게 ssl이 없다고 합니다.
근데 아무 ssl 인증서나 되는 건 아닐 꺼 아냐! 해서 좀 찾아보니… 일단 깃헙에 이슈에 대한 쓰레가 있습니다. 좀 한참 밑으로 쭉 내려가면 명령어 쳐서 만들어라 하는 데 그 명령어가 이겁니다.
openssl req -x509 -nodes -days 365 -subj /CN=Barrier -newkey rsa:4096 -keyout Barrier.pem -out Barrier.pem
그래서 해당 디렉터리로 이동해서 작업을 진행했습니다. 전 윈도우에서 이용하는 wsl의 우분투를 이용해서 직접 만들었습니다. 윈도우 사용자 분들은 openssl 윈도우 설치 프로그램 이용하셔서 하시면 되고, 리눅스나 맥은 뭐… 이미 있을수도 있습니다. (자기가 모르는 사이에 패키지 설치하면서 깔렸을 수 있습니다.)
저렇게 만들고 나서 Barrier를 다시 실행하거나, 중지 후 시작을 다시 하면 로그 내용이 바뀌어있을 것입니다.
그러면 이제 다른 컴퓨터에서 클라이언트를 실행하면, 서버 화면에는 자기 컴퓨터 기준으로 어디에 배치할 것인지를 선택하는 화면이 나옵니다. 선택한 후에는 클라이언트에도 뭔가 뜨는데, 바로 ssl 인증내용을 보여주면서 이 클라이언트와 연결 승인할 것인지를 묻습니다. 승인하게 되면 바로 연결되어 제어할 수 있게 됩니다.
워낙 유명한 프로그램이라서 사용하는 내용은 간단하게 적힌 블로그 글들이 여럿 있는데, ssl fingerprint 설정에 대해서는 잘 안적어놔서 정리 좀 해봤습니다. 간만에 블로그 적는데 생각보다 글이 잘 안써지네요. ;ㅅ;
다시 잘 써서 C언어 글 완결지어야 되는데 말입니다. ;ㅅ;
오늘은 간만에 블로그 글 좀 쓰는 연습 겸 해서 오픈소스 프로그램 하나 소개해 보려고 합니다.
여러분 작업하면서 컴퓨터 몇 대 쓰시나요? 전 윈도우, 맥, 리눅스 가리지 않고 여러대 이용하고 있습니다. 이러면 반드시 키보드랑 마우스를 여럿 쓰게 되는 불상사가 발생하는데…. 책상이 완전 엉망진창이 되죠. ;ㅅ;
그래서 보통 kvm 스위치라는 하드웨어를 이용하게 됩니다. 이름 그대로 키보드, vga, 마우스를 이어주는 제품으로, 하나의 모니터, 키보드, 마우스를 가지고 여러대의 컴퓨터에 연결해서 버튼으로 선택해 연결해주는 장치를 이용합니다. 주로 서버 렉에서 렉 하나 구성할 때, 가운데에서 여러 서버들 설정하고 할 때 주로 이용합니다.
이건 집이나 사무실에서 쓰는 스타일입니다. 사진의 모델은 좀 고급 모델이라 듀얼 모니터도 지원됩니다. 당연히 비쌉니다. 한 60만원 하려나..?
그리고 이런 녀석들이 랙에 서버들 구축할 때에 서버 설정 한곳에서 할 수 있도록 하는데 이용하는 kvm입니다. 랙 한번 구축해보신 분들은 잘 알겠지만, 서버에는 저런 전용 kvm 연결단자 연결하고, 가운데에 전용 터미널 사다 달아서 하나하나 그냥 그자리에서 바로 셋팅할 수 있도록 많이들 해놓습니다. (사실 랙마운트 뒤에 선이 많은 것도 네트워크 케이블이나 SAN 스토리지일수도 있지만, kvm일수도 있습니다.)
근데 저런 걸 쓰기도 뭐하고 해서 소프트웨어 방식의 kvm을 찾아보면 유명한 녀석이 하나 튀어나옵니다. 바로 synergy라는 녀석인데, 아쉽게도 이녀석은 유료입니다. 그래서 이녀석의 오픈소스판인 Barrier를 이용하고자 합니다. 윈도우, 맥, 리눅스에서 다 되면서 오픈소스라니..! 이건 해야되! 라는 수준입니다!
설치 방법 자체는 간단합니다. 사용법에 대해서도 설정의 거의 대부분은 auto config가 되어있어서 그렇게 어렵게 하진 않고요.
이거 사용법 좀 정리해서 다른 것보다 설정 내용이 헷갈릴 수 있어서 그러는데, 제 기준에서 좀 헷갈렸던 내용을 다음 글에 정리해서 올려보겠습니다.
외주로 플러터 앱 개발 작업을 하고 있는 도중에 이번에 안드로이드 스튜디오가 업데이트 되었더군요. ㅎㅎ….
보통이었으면 업데이트를 안했을 텐데, 왠지 모르게 이건 업데이트를 해야 할 거 같았습니다. 구글 애드몹(AdMob) 적용하는 pub도 안드로이드 업데이트 땜에 맛이 갔던 기억도 있고, Gradle 버전 땜에 짜증났던 경우도 상당히 많았기에 업데이트를 통해서 확인해야 할 듯 하더군요. 이건 또 무슨 문제 터질것인지를 생각하면 진짜….
(근데 iOS에서는 진짜 아무 문제도 없이 잘 실행되던 거 보면 더더욱 열받습니다. 그러니 여러분 제발 아이폰 쓰세요.)
뭐, 저한테 플러터는 지금 버전 업되면서 여러모로 충돌나는 좀 많이 짜증나는 녀석으로 인식이 박히고 있었는데… 이건 좀 경험 공유를 해야 할 거 같습니다.
일단 안드로이드 스튜디오가 업글되고, 개발 화녁이나 API 업글이 되고 나서 갑자기 이런 메시지가 발생하기 시작합니다.
에러 메시지의 주 내용은 제목에 적은 내용 그대로 ndk toolchain을 찾을 수 없다는 내용입니다.
근데 이런 오류가 나면, 보통을 플러터 환경 문제일 것이라고 가장 먼저 떠올릴 수 있습니다. 당연하잔하요. ndk toolchain이 없다니… 이건 뭐 설치 오류 아니겠어요?
근데 이걸 공유하고자 맘먹은 이유는….
flutter doctor, flutter doctor -v로 돌려도 정상으로 나옵니다. 아래처럼 말이죠…
어떤 크로스플랫폼 이용하는 녀석들 중에 ndk 안쓰는 녀석이 어딨다고?! 이미 설치 다 해놨을텐데 왜?!
검색해보니 다행이도 쓰레가 있습니다. (링크도 걸어둡니다.) 다른 곳에서 다른 사용자가 비슷하게 질문 올렸는데 전부 이 스레 하나로 통일되어 나옵니다.
근데 뭐 이 쓰레 제대로 이해 못할 분들을 위해 결론부터 적으면, 안드로이드 스튜디오의 ndk 버전 다운그레이드 하시면 됩니다.
안드로이드 스튜디오에서 SDK Manager를 통해 SDK를 확인하고 SDK Tools에서 NDK가 그냥 체크 표시 되어있는 경우에는 업데이트 하면서 NDK도 그냥 자동으로 업데이트 된 상황인 것입니다. 전 이미 버그 안나도록 다운그레이드 해서 저렇게 되어있을 뿐…
그럼 이전 버전은 어떻게 설치하냐고 물으시면, 아래와 같이 Show Package Details를 클릭하면 설치 가능한 버전들을 보여줍니다.
그리고 원하는 버전의 ndk를 체크하고, 최신 ndk를 체크 해지해서 지워줍니다. 그리고 적용하면 바뀐 버전으로 설치가 진행될 것입니다. (ndk 설치는 시간이 오래 걸립니다.)
그리고 나서 버그난 플러터 프로젝트 다시 빌드하면 저 오류 어디서 튀어나왔냐는 듯이 없어집니다.
이거 스레 내용이 이해가 제대로 안되어서 정신 차리고 제대로 보고 다시 하느라 솔직히 하루 이틀 날려먹은 것도 어이가 없긴 한데….
ndk 버전 타기 시작하면 진짜 열받습니다. 다행이 지금 쓰고 있는 pub들 중에서 낮춘 ndk에서 문제 안터지게 되었으니 다행인데, 만약 계속 써야 하는 녀석이 ndk 버전 타고 하면 골때려지기 시작하는데….
다른 버전 충돌과 문제인 것은, 보통의 버전 충돌이나 참조 충돌같은 경우에는 각각이 다 독립적인 라이브러리들이다 보니 그냥 버전을 맞춰준다 = 그냥 개발자만 좀 불편해진다에서 끝날 수도 있는데 이런 건 그냥 운영체제 동작환경 자체에도 영향을 주는거니…
차후에 새로운 프로젝트로 해보면서 확인 좀 해봐야겠지만… 이건 좀 많이 위험하네요.
예전에 Cocos2d-X 할 때 생각나서 더 머리아프군요….ㅠㅠ
p.s. 이런 오류 안터지게 잘 개발하는 분들도 있겠지만, 그냥 플러터에 올라온 거 잘 이용하면 뭔 문제 있겠냐 수준의 분들이라면 그냥 더 이상 할 말은 없습니다.
gitlab….. 상당히 편한 녀석이다. 규링은 시놀로지에서 엄청나게 잘 쓰고 있기도 하고…
근데 어떤 썩을 것 땜에 시놀로지 나스 시스템이 망가졌다. ㅠㅠ
뭐, 이 기회에 욕심나던 작업도 있고 해서 데이터를 일단 외장하드로 다 뜬 다음에, 그대로 공장 초기화를 시키기로 해서 초기화 진행. 그리고 필요한 것들을 하나 하나 설치하고 있는데….
gitlab 설치할 때에는 패키지 구성되어 있는 걸 설치해서 간단하게 설치하자 해서 패키지 센터에 있는 녀석으로 설치를 했다. 자기 혼자 알아서 도커도 깔아주고, 자기 혼자 알아서 이미지 떠서 도중도중 입력한 smtp 정보나 도메인 정보, 관리자 계정 이메일 등의 여러 설정값 넣어준대로 알아서 잘 되나 싶은데…
계속 시작도 못하고 죽는다…!
자꾸 데이터베이스 관련해서 죽는다….
….이게 왜 이런가 싶어서 자동으로 만들어진 도커들을 살펴보는데 거기에 답이 있었다.
내가 안되던 때에는 맨 위에 있는 gitlab 본체의 컨테이너만 실행이 안되어있었다. 근데, 그 밑에 DB쪽인 postgresql은 멀쩡하게 돌고, redis도 멀쩡하게 돌고 있었다. 그 말인 즉, 본체에서 디비에 접근을 못해서 지 멋대로 꺼진 건데…
그럼 걍 네트워크 브릿지가 막힌거네..?
해서 브릿지 정보를 확인하고….
브릿지 정보에 있는 저 IP와 서브넷 정보를 방화벽에서 규칙 허용을 해줘야 한다…! gitlab 포트의 방화벽 허용과는 별개로..!
그전에 정보 적고 올린 것들은 아마 방화벽 설정따윈 하나도 안한 채로 막 쓰고 있는 것들이겠지….!!!! 머리를 장식으로 달고 글쓰는 거냐..!!!!!
방화벽을 적용하는 데에는 규칙이 있다. 아무것도 없으면 방화벽은 동작 안하는 거나 마찬가지이다. 그래서 허용할 규칙에 대해서 해당 소스가 되는 ip 정보와 포트 정보를 입력하여 허용을 진행하고, 그 외에는 전부 거부를 하는 것이다. 그렇게 해서 허용하는 목록만 허용하게 되고 나머진 다 막는 것이 방화벽 적용 규칙이다. 이 부분에 허용을 안했으니 막힐 수밖에….ㅠㅠ
분명 아무것도 안하고 그냥 설치했더니 바로 실행되었어요 하는 것들… 방화벽 규칙이나 보안 규칙 빡시게 안잡은 것들일꺼다 분명…
근데 보안 땜에 방화벽을 먼저 설정 싹 다 해놓고 gitlab을 설치해서 쓰니깐 gitlab은 도커 브릿지 네트워크 통해서 네트워크 인터페이스가 되어 있으니 당연하게도 저쪽에서 막힌 것이다. 그러니 저쪽을 열어주면 해결.
참고로 라우터에서 포트포워딩까지는 안열어줘도 된다. 실제로 외부로 포트포워딩을 해야 하는 gitlab 접속할 때 이용할 포트(시놀로지 패키지 기본 설정 포트가 둘 있다. 그 둘만 해줘도 됨.)는 방화벽도 허용해줘야 하는 것이긴 하지만, 라우터의 포트포워딩쪽에서는 브릿지쪽은 안해줘도 외부 접속은 문제 없다. gitlab 구성요소들간의 통신의 문제를 해결하기 위한 것이니 나스의 네트워크 방화벽만 허용되어도 된다.
이거 땜에 시간은 날려먹었지만….
잊을만한 내용을 다시 상기하기에는 좋은 것 같아서 공유를 하려고 한다.
이런 정보는 삽질하면서 얻은 거니 블로그 글로 남겨야지….ㅠㅠ
p.s. 해당 서비스마다의 ip를 열어주는 것도 좋지만, 방화벽 설정 규칙이 너무 번거로워지기 땜누에 별로 추천하고 싶진 않다. 포트 범위는 nmap 같은 곳에서 잘 안잡히지만 특정 포트는 nmap으로 쉽게 스캔되기 때문에 공격 당하기 참 좋은 구실을 만들어 줄 수도 있다.
정말 오랜만에 쓰는 블로그이자, 개발자와 건강 시리즈인듯 하다..
규링도 솔직히 IBM(이미 버린 몸)인지라, 내 몸만 가지고도 개발자와 건강 시리즈를 여럿 쓸 수 있을 거라 생각했는데… 정작 규링이 걸리지 않는 병이 있다는 걸 깨달았다.
바로 치질.
(전조조차 없다)
개발자들 의자에 오래 앉아있는 특성상 치질은 피할 수 없는 거라고 생각한다.
이 치질이 은근 장시간 앉아있는 직업의 경우에 은근 많이 생기는 녀석인데 난 아직 걸린 적이 없다고 은근 무시하고 있던…
근데 일단 내 주변에 걸린 이야기 들리니 갑자기 확 들었다.
치질 있는 분들과 의자의 상관관계를 생각해봐야겠다고…
그냥 가끔 일어나서 혈액순환 좀 시켜주고, 그리고 상시 바른 자세로 앉아서 압력을 잘 분산시켜야 한다는 거 외에는 의자와 관련된 거로는 잘 안떠오르지만, 사실 이건 치질 아니어도 중요한 것인지라…
게다가 자극적인 거 먹지 말고, 위생 잘 챙기고, 설사랑 변비 안생기도록 해야 하는 것도 다른 것들의 건강습관과 연결되어 있고…. 적당량의 물 마시고, 음주 하지 말고…
쓰고 보니깐 그냥 치질 관련된 것도 언급하면서 이걸 끝내야 할지도 모르겠다. ;ㅅ;
….이걸 진짜 시리즈로 엮어서 정리하는 것만으로도 아무래도 책 내용 나올 거 같은데…ㅇㅅㅇ;;;
p.s. 일단 이런 걸로 언급이라도 해야 경각심이 생길 거 같습니다. 진심…
