Mac OSX에서 로그인시 자동으로 시작되는 프로그램을 삭제 하는 방법들은 대략 다음과 같다.
태스크 바에서 오른 클릭 후 ‘로그인 시 열기’ 해제
설정 -> 사용자 및 그룹 -> 로그인 항목에서 삭제
/Users/<사용자계정>/Library/LaunchAgents/에서 unload
/Library/LaunchAgents/에서 unload
사용자 계정에 등록된 로그인 항목 unload (위의 3번)
위의 1번과 2번 방법은 인터넷에 많이 있으니, 테스크바에도 등록되어 있지 않고 설정의 로그인 항목에서도 프로그램이 보이지 않는 경우, 사용자 디렉토리 내의 LaunchAgents에서 찾아 삭제를 시도해 볼 수 있다. 다음은 CrashPlan이라는 프로그램을 사용자 계정 시작 항목에서 삭제 하는 예시이다.
Mac version Docker에 띄워둔 web server에 host에서 접속하려면 어떻게 해야 할까? 실행할 때 ‘–network=host’를 주면 된다는 얘기가 있어서 해봤는데, Mac에서는 통하지 않았다 이건 linux용이라고… Networking features in Docker Desktop for Mac에 따라 실행할 때 port를 매핑하는 것으로 이 문제를 해결할 수 있다.
Docker의 9090 port에 Mac의 9090 port로 접근하려면 다음과 같이 -p option으로 port를 매핑해서 docker를 띄운 후 서버를 실행한다.
# Port 매핑으로 docker를 실행
MAC$ docker run --rm -ti -p 9090:9090 DOCKER_IMAGE
# Docker에서 웹서버를 띄운다. Python http.server module을 사용.
DOCKER$ python -m http.server 9090
Serving HTTP on 0.0.0.0 port 9090 (http://0.0.0.0:9090/) ...
GitLab Runner 문서를 보고 열심히 따라하고 설정까지 마쳤는데 러너가 동작하지 않고 commit을 하면 CI가 한 참 동안을 pending 상태에 있다가 실패했다는 에러 메일 보내 버리는 증상이 있다. Systemctl로 서비스 상태를 보니 제대로 올려지지 않고 ‘inactive’이거나 ‘activating’에 계속 머물러 있다. 하지만 만약 background 서비스로 동작시키지 않고 다음과 같이 run command로 foreground에서 돌리면 잘 동작한다. 환경 설정에는 ‘거의’ 문제가 없다는 뜻 이겠지..
$ sudo /usr/local/bin/gitlab-runner run
Journalctl로 서비스 로그를 보니 FATAL에러가 하나가 잡힌다.
$ journalctl -u gitlab-runner.service
...
gitlab-runner[4622]: FATAL: the "HOME" is not set
systemd[1]: gitlab-runner.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: gitlab-runner.service: Failed with result 'exit-code'.
오호라. HOME 환경 변수를 찾으려 했는데 없어서 죽은 거고만! 해결책은 간단히 HOME 환경 변수를 선언해 주면 된다. 서비스 설정파일 (/etc/systemd/system/gitlab-runner.service)를 열고 [Service] 항목에 환경 변수를 추가해 준다. 만약 proxy환경이고 환경변수로 설정하고 있다면 서비스에서는 환경변수를 접근할 수 없으므로 여기에 함께 선언해 준다.
[Unit]
Description=GitLab Runner
After=syslog.target network.target
ConditionFileIsExecutable=/usr/local/bin/gitlab-runner
[Service]
Environment=HOME=/home/gitlab-runner # 이 부분을 추가
# 해당하는 경우 proxy 설정
#Environment=no_proxy=노프록시 설정
#Environment=NO_PROXY=노프록시 설정
#Environment=http_proxy=HTTP프록시 주소
#Environment=HTTP_PROXY=HTTP프록시 주소
#Environment=https_proxy=HTTPS프록시 주소
#Environment=HTTPS_PROXY=HTTPS프록시 주소
StartLimitInterval=5
StartLimitBurst=10
ExecStart=/usr/local/bin/gitlab-runner "run" "--working-directory" "/home/gitlab-runner" "--config" "/etc/gitlab-runner/config.toml" "--service" "gitlab-runner" \
"--syslog" "--user" "gitlab-runner"
Restart=always
RestartSec=120
[Install]
WantedBy=multi-user.target
여러 국내 호스팅 업체들을 거쳐서 여러 곳에서 WordPress 호스팅 서비스로 추천되는 Siteground에 한동안 정착하는 듯 했다. 준수한 속도에 비해 합리적인 가격($3.95/월) 때문에 당분간 정착할 거라고 생각하고 있었는데 일년이 지나서 서비스 갱신기간이 되자 가격이 세배 넘게 올라서 1년에 $143을 달라고 한다.($11.95/월). “이건 너무 한 거 아니냐고!”
WordPress hosting은 더 비싸다
대안으로 생각한 것은 1) wordpress.com hosting과 2) AWS Lightsail이었는데, 발견한 한 가지 놀.라.운. 사실은 WordPress hosting에서 플러그인을 설차하려면 한달에 $25 짜리 business plan 이상을 계약해야 한다는 것이다. 한달에 $25라니!!! 멋 모르고 카드 결재를 하고 이리저리 플러그인 설치를 시도하다가 아래의 표를 발견하고는 미련 없이 ‘refund’ 버튼을 눌렀다.
AWS Lightsail은 한 달간 무료 시험기간을 주기 때문에 Siteground 계정이 종료하기 전에 미리 설치를 마쳤다. 인스턴스 리전을 한국으로 할까 하다가 이전 Siteground와 같은 위치인 싱가포르로 선택했고 WordPress의 export/import 기능 덕에 마이그레이션은 수월하게 진행되었다. Domain name은 호스팅 업체와 같은 곳으로 이전하는게 좋다고 해서 AWS Route 53으로 이전 및 1년 연기 등록을 했는데 상위 도메인에 따라 다르지만 .com의 경우 $13.2(세금포함)가 소요된다. 어라? 그러고 보니 Siteground에서 도메인을 연장하는 서비스는 $15.95였는데? 이눔 시키들…
도메인 이전과 새로운 IP 연결
도메인 이전을 요청하니 이전 관리자였던 Siteground에서 확인 메일이 왔고, 수락한 이후에는 하루 후에 AWS로 도메인이 이전되었다. 그 후에는 Lightsail의 네트워킹 탭에서 고정 IP와 DNS 영역을 생성해서 A 레코드를 추가하고 IP와 도메인 이름을 연결 시켜 주었다.
그리고 나서 한참을 DNS가 업데이트 되기를 기다렸다. nslookup은 여전히 예전 IP를 보여줬지만 48시간 까지 걸릴 수 있다는 말에 이틀정도를 기다렸는데도 IP가 업데이트 되지 않았다. AWS Route 53에 가보니 ‘registered domains > [domain name]’ 아래에 Name Servers 항목이 있는데 혹시 이것 때문인가 싶어서 고정 IP를 만들때 나왔던 네임서버 목록으로 업데이트를 해주었다. 그리고 나서 잠시 후 드디어 새로운 IP로 접속되었다!
계속 예전 IP로 돌아가는 도메인 문제와 해결
기쁜 마음으로 꿀잠에 들었는데 다음날 아침에 보니 Jetpack에서 서버연결 붙었다가 끊어졌다가 했다는 연락이 와 있었다. 혹시나 싶어서 서버를 재부팅 해봤더니 재부팅하는 순간 잠깐 IP가 새 것으로 붙었다가 다시 예전 IP로 돌아가는게 보였다. “그니까누가 AWS가알고있는것과다른예전정보를자꾸준다는거지…” 혹시나 하는 마음에 Siteground의 cPannel > Advanced DNS zone editor에 들어가 봤더니 역시나 얘가 예전 주소를 꼭 쥐고 있었다. 예전 사업자의 도메인 서버를 AWS 고정 IP로 수정해 주고 났더니 Jetpack이 사이트 살아났다고 축하한댄다. 다행히 그 후로는 다시 끊어지는 일은 없었다.
도메인 관리자를 변경하고 새로운 IP를 연결 했으니 이전 네임 서버에서는 자동으로 놔 주겠거니 하고 잘 못 생각하고 있었던게 문제 였던듯 싶다.
설치된 Java runtime에 맞게 Tomcat download page에서 적절한 binary distribution을 download받고 설치해준다. Tomcat website에 있는 Which version? 항목을 보면 아래와 같이 표가 나오는데, “Supported Java Version”을 참고해서 적합한 “Apache Tomcat Version”을 선택하면 된다. 예를 들어, OpenGrok의 경우 Java 1.8이 requirement이므로, Tomcat version 9.0.x이상을 선택하면 된다.
모든 설정이 끝났다면 Tomcat을 설치한 머신에서 http://localhost:8080/manager/html 주소에 접근해서 Tomcat 서버 설정을 관리 할 수 있다. ID와 password를 묻는 prompt가 뜨면 위의 tomcat-users.xml에서 설정한것 처럼 ID/비밀번호(tomcat/비밀번호(password)를 입력한다.
Remote Access 허가
Tomcat 관리자 page를 접근할 때 localhost가 아닌 remote에서 접속을 시도하면 403 access denied 오류가 뜰 수 있다. Localhost외에서도 tomcat 관리자 page 접근을 허용하려면 아래 경로에 있는 context.xml file의 allow= 부분을 수정해서 모든 IP를 받아들이도록 변경해 주면된다. context.xml은 여러개 있으니 경로에 주의.
