Local VNC server는 접속이 가능하지만 외부에서 접속이 불가능 하다면 SSH tunneling을 설정해서 연결을 시도할 수 있다.
VNC Client에서 SSH Tunneling을 지원하는 경우
SSH tunneling을 지원하는 VNC client인 Remmina와 같은 경우에는 다음과 같이 서버로 localhost:5901을 설정한다. 여기에 서버 IP가 아니라 localhost를 적어주는게 좀 이상해 보이긴 하지만 SSH tunneling을 설정한 상태에서는 localhost의 5901번이 remote server의 VNC service를 제공하도록 연결된다.
그 다음에는 SSH Tunnel 탭을 선택해서 다음과 같이 정보를 입력한다. Enable SSH tunnel을 클릭해서 활성화 하고, 서버의 IP와 SSH가 서비스되는 port번호인 22번을 적어준다(SERVER_IP:<SSH_PORT>). 로그인 방식은 설정에 따라 적어 준다. 나는 SSH key login을 선호하므로 SSH Identity file을 선택하고 private key를 설정해 주었다.
SSH Tunneling 설정이 없는 경우
TigerVNC와 같이 명시적으로 SSH tunneling을 지원하지 않는 경우에는 터미널을 하나 열어서 다음과 같이 SSH tunel을 하나 열어 준다.
Release package를 생성할 때 넣는 version의 이름은 github.ref_name으로 참조 된다. 첨부되는 파일의 이름은 prebuilt-<version_tag>.zip으로 설정한다. 참고로 GitHub에서는 release에 추가되는 소스코드외의 파일들을 “Asset”이라 부른다.
빌드 수행 및 Asset 생성
# Checkout source code and build Android APKs.
- name: Checkout
uses: actions/checkout@v3
- name: Setup JDK 17
uses: actions/setup-java@v3
with:
java-version: '17'
distribution: 'temurin'
cache: gradle
- name: Build Android APK and zip
run: |
sh ./gradlew assemble
zip ${{ env.ASSET_FILE_PATH }} \
./app/build/outputs/apk/debug/app-debug.apk \
./app/build/outputs/apk/release/app-release*.apk
Android build를 위한 JAVA를 설정하고 Gradle의 assemble target을 설정하여 APK file에 대한 빌드를 수행한다. Assemble은 debug와 release용 두개의 apk를 성성하므로 이들을 하나의 zip파일로 만들어서 prebuilt-<version_tag>.zip에 추가한다.
Release에 Asset 추가
Release에 asset을 추가해주는 GitHub action은 보이질 않는다. 그래서 GitHub script를 이용해서 release에 asset을 추가하는 동작을 다음과 같이 정의했다. 이는 두 개의 동작으로 이루어지는데 하나는 주어진 tag로 release 정보를 찾아오는 것이고, 다른 하나는 가져온 release 정보에 파일을 업로드하는 것이다.
동작 1. Tag로 release 가져오기
GitHub script project의 README.md에 따르면 GitHub script상에서 github객체는 사전인증된(pre-authenticated) Octokit client라고 한다. 따라서 새롭게 instance를 만들지 않고 바로 Octokit의 API를 사용할 수 있다. getReleaseByTag()에 tag를 넘겨주면 통해 release에 대한 객체가 반환된다. 그 중에 release를 구분하기 위한 ID만 사용한다.
// Get a release for given tag.
const release = await github.rest.repos.getReleaseByTag({
owner: context.repo.owner,
repo: context.repo.repo,
tag: process.env.TAG
});
const release_id = release.data.id;
console.log("Release id for the tag " + process.env.TAG + ": " + release_id);
동작 2. Release에 파일 업로드 하기
앞의 과정에서 만든 업로드할 zip파일과 release를 구분할 ID 정보를 uploadReleaseAsset()에 넘겨 주면 해당 파일이 asset으로 등록된다.
// Upload release assets.
const fs = require("fs");
const filename = process.env.ASSET_FILE_PATH.replace(/^.*[\\/]/, "");
var uploaded = await github.rest.repos.uploadReleaseAsset({
owner: context.repo.owner,
repo: context.repo.repo,
release_id: release_id,
name: filename,
data: await fs.readFileSync(process.env.ASSET_FILE_PATH),
});
console.log(
process.env.ASSET_FILE_PATH
+ " has been uploaded as " + filename
+ " to the release " + process.env.TAG);
주의: upload 동작은 release를 수정하는 것이므로 workflow가 repository에 대한 write permission이 있어야 하므로 settings 항목에서 에서 write permission이 허가되어 있는지 확인한다. 이 부분이 안되어 있다면 403 error가 날 것이다.
Release workflow 실행
GitHub repo의 Code 탭에서 Tags -> Releases -> Tag -> Draft a new release를 선택한 후 Choose a tag를 눌러서 나오는 입력창에 새로 생성할 version tag를 입력해 Create new tag를 선택한 다음 Publish release 버튼을 누른다.
이 때 만들어지는 release에는 소스코드만 들어 있지만, 정상적으로 동작했다면 Actions tab에 release workflow가 등록되어 수행되는 것이 보일 것이다. Workflow가 정상 종료된 후 해당 release로 다시 가보면 asset이 등록되어 있는 것을 볼 수 있다.
WordPress에서 몇 번 플러그인 업데이트 실패에 대한 알람이 왔었는데, 오늘에야 살펴보니 자동은 물론 수동 업데이트도 계속해서 실패하고 있었다.
새로 릴리즈된 WordPress 6.3에서 플러그인과 테마를 롤백할 수 있는 기능이 추가되었는데, 이 기능을 위해 wp-content/upgrade-temp-backup/plugins와 wp-content/upgrade-temp-backup/themes 디렉토리를 사용하는 모양이다. (관련 기사 링크)
문제의 원인은 간단했는데, wp-content 디렉토리의 쓰기 권한이 daemon에게 없기 때문에 디렉토리를 만들지 못하고 실패하는 것이었다. 따라서 간단히 디렉토리를 수동으로 만들고 권한을 할당해 주는 것으로 해결되었다.
콘솔에 접근해서 다음과 같이 명령어들을 입력한다.
# WordPress경로로 이동해서
#e.g) cd ~/apps/wordpress/htdocs
# 디렉토리 경로를 만들어주고
mkdir -p ./wp-content/upgrade-temp-backup/plugins
mkdir -p ./wp-content/upgrade-temp-backup/themes
# 소유권 그룹을 할당한 다음
sudo chown bitnami:daemon -R ./wp-content/upgrade-temp-backup
# daemon group에 쓰기 권한을 준다.
chmod 775 -R ./wp-content/upgrade-temp-backup